[HN Gopher] Reframing Tech Debt
___________________________________________________________________
Reframing Tech Debt
Author : kiyanwang
Score : 16 points
Date : 2021-11-21 14:43 UTC (8 hours ago)
(HTM) web link (increment.com)
(TXT) w3m dump (increment.com)
| legerdemain wrote:
| Is this the final issue of Increment? Has Stripe decided what, if
| anything, will replace it?
| mr_tristan wrote:
| I've found most "tech debt" planning to be incredibly vague and
| nebulous. Many engineers can identify what makes them
| uncomfortable, but it takes real effort to fully explain why, and
| what the real impacts are.
|
| Maybe trying to think about "tech wealth" or "tech capability"
| might change this. Instead of a ticket to "improve error
| handling" it's "ensure the system can recover from a DNS failure
| safely to the DB without manual intervention". This sounds more
| like a feature, because, well, it is.
|
| I've found most of the places talk a _lot_ about having good
| quality, but few actually did anything concrete about it. Most
| changes ended up not making any impact. And this is over the
| course of a 20 year career.
| sktrdie wrote:
| I'm curious how largish software projects are organized to deal
| with tech debt. Is it just ingrained and taken into account for
| say 20% of the work at each sprint planning? Is there a specific
| team dedicated to doing tech debt stuff? Do people just work on
| tech debt when they feel like it? Are there just a few people in
| the team that like to go around the project and take on smallish
| tech debt tasks?
|
| I'm curious because our team is struggling with tech debt. We are
| divided in feature teams and I had this idea of maybe simply
| having a "tech debt team" that, just like feature teams, has
| sprints achieving tech-debt related goals such as "improve
| startup times by 10%" or "decouple router module from auth
| module" or "setup webpack to tree-shake modules" etc.
|
| How do y'all do it?
| taeric wrote:
| I've rarely seen directly working on tech debt actually pay
| off. You either get stuck fixing last year's problem, or you
| lose the race to feature parity with where you were.
|
| To that end, keep cleaning as you go. And accept that good
| development can be like a good batter. Probabilistically good.
| Not certain.
| ahdh8f4hf4h8 wrote:
| I have always done "just in time" refactoring - when a big
| change comes to a module and you're going to have to re-test
| most of it anyways, then perform the refactor, test the
| code/module, and then implement the actual change. It helps if
| you have some long term vision for the product, so you have
| some idea of future changes as well.
|
| You want to avoid refactoring if no one else is going to test
| the change, or if your automated test coverage on the module
| isn't too good. It's too easy to introduce changes that won't
| be noticed before deployment.
|
| Chances are most code already works well enough even if the
| design or code is suboptimal - often the system only changes in
| certain parts and changes there often. If you can identify the
| parts of your system that are likely to change due to changes
| in scale or business requirement, than that is a natural area
| to focus on in future redesigns or refactoring.
| wpietri wrote:
| > I had this idea of maybe simply having a "tech debt team"
|
| Please don't do this. If it's one team's job to clean up the
| messes other teams leave, you've created a terrible incentive
| for other teams around working clean.
|
| I remember one place where each project had a fixed-in-advance
| schedule and engineers were rotated among projects based on
| whoever was available when the project officially started.
| Since people rarely worked in the same area of the code base
| from project to project, the incentive was to get something
| working and then GTFO. The code of course got steadily worse.
| So then the company would compensate with major rewrites of the
| most garbage-y sections.
| joshz404 wrote:
| I like it. I've also found success as framing it as building tech
| capability. Focusing people on adding capability or wealth,
| positive connotations, I think is the way to go.
| wpietri wrote:
| I think this is a mistake a lot of people make:
|
| > Carving out time to pay down tech debt requires buy-in from
| leadership.
|
| Not in my experience! I think one can do pretty well a) refusing
| to put debt in to begin with, and b) for any new work, including
| necessary cleanup of what you'll be touching in the estimates.
|
| Some years back I had an explicit understanding with a product
| manager: the engineers would track tech debt and take care of it
| in small slices over time. He could always ask for details, but
| absent his curiosity, we'd just leave him out of it, doing a
| little bit every week so that things always stayed in good enough
| shape that we would keep our velocity high and our surprises low.
| Early on he asked a couple of times, but he quickly realized that
| to him it was entirely boring.
|
| I think it's a mistake to ask non-experts to prioritize things
| they don't understand. You're not going to ask your execs if it's
| ok for you to take time to eat or brush your teeth. You equally
| shouldn't ask them if it's ok to be a responsible professional
| and do things like writing tests and keeping the code base
| reasonably clean. That should just be part of the deal; any
| exceptions should be temporary and carefully negotiated.
| infogulch wrote:
| This is my preferred strategy, but gets muddled when managers
| micro-manage code reviews. Maybe that's just a sign of a toxic
| work environment.
|
| > You're not going to ask your execs if it's ok for you to take
| time to eat or brush your teeth.
|
| I like this! I could add: machine shop workers don't ask if
| it's ok to clean up the mess after a job.
| jeffbee wrote:
| I don't know if I like this framing at all. If your company has
| fostered an atmosphere where there seems to be tension between
| writing unit tests and shipping features, you've already screwed
| it up. If you divide your development schedule between shipping
| features and writing tests you are simply enabling the bad actors
| in your organization to inevitably short-change that part of the
| cycle.
| afarrell wrote:
| I've worked on a team that explicitly aimed to budget about
| 10-20% of its time on "tech investment" projects to
| expand/protect our capability to deliver. We also delivered
| fairly predictably on business goals. It was glorious.
| ahdh8f4hf4h8 wrote:
| Personally, I no longer use the phrase "technical debt" when
| speaking to management. It's just too vague of a term. Instead I
| just explain the actual problem and the consequences - too much
| near duplicate code leading to slow maintenance, non-scalable
| design choices leading to slow processes, rigid design choices
| which hamper the team from implementing the upcoming stories,
| excessive complexity leading making the code hard to change.
|
| Once you get our of analogies and into actual problems, then you
| can have a reasonable discussion about future tradeoffs. I find
| even with non-technical managers, debt/wealth is just not a good
| analogy for code.
|
| Also, often poor code is just part of a larger process problem.
| You really need to optimize for the whole project, not just code-
| level to improve the situation.
| redroot wrote:
| I've also found the term quite dangerously misleading. The
| 'tech' part of the statement makes it sound like the 'debt'
| that is getting in your way it's purely a concern of the
| engineering function, where it should be a concern of the
| business. The 'debt' part is also confusing - I have seen non-
| technical stakeholders thinking it can be dealt with like
| financial debt with more revenue or VC rounds in one lump sum,
| we don't have to worry about it because are a growing startup
| and debt is normal.
|
| Two alternative explanations I've begin to use over the last
| few years that have helped:
|
| 1) Inertia / Inert Areas - the reason this 'debt' is a problem
| is it means future changes are hard to execute cleanly, and
| previously. An area becomes inert to change unless an
| intervention is made. For non-technical stakeholders they most
| important thing is often that we can keep making changes, so
| this sets all sorts of loss aversion alarm bells ringing in a
| way the term 'debt' doesn't - this is where you can start
| talking about risk, which crosses the divide between
| engineering and other functions quite well.
|
| 2) Product Debt - Yes in some cases code is just badly written,
| which is an engineering concern, but often the reason changes
| in Year 5 are hard to make because the domain / reality has
| moved on, and the assumptions baked into the code written in
| Year 2, no matter how clean the code, are now just wrong. For
| example, baked-in assumptions of how business works in Market A
| as you are expanding into Market's B and C. This isn't the
| fault of engineering, just the reality of a product that
| continues to persist - core changes are inevitable. Product
| leaders therefore need to also get strategic about when it
| makes sense to rethink previous decisions driven by product
| needs, and work with engineering leaders to mitigate otherwise
| you might end up in an inert ball of mud unable to hit goals.
|
| In the most idealised vision of a piece of software, changes
| will get harder to make in a linear fashion if previous
| decision are not revisited will new information. In worst case
| it's more like an exponential graph, so intervention steps will
| always have to be taken.
|
| As you say, once you're talking the same language, then you get
| into the details about what strategies to address this inertia
| / current conditions.
___________________________________________________________________
(page generated 2021-11-21 23:00 UTC)