Would be interesting to apply game theory to tech debt, because it is, after all, The Great Game we all play, whether we admit it or not.
How would you imagine it? Sounds interesting indeed!
How to approach and prioritize technical debt
21–30 of 55 posts
Re: How to approach and prioritize technical debt
#22Debt would be if someone said "I need to build a bridge across here that can handle an Army, and I've got $1m", we engineers reply "It will take $2m", and they respond "Ok, I will borrow $1m so you can build the bridge I need".
Instead what happens is they say "Well, build what you can for $1m", and you say "Ok, we can make 'a bridge' for that", and then either (a) your infantry can cross, but the tanks have to get diverted 20 miles out of the way, or (b) the tanks end up in the river along with the bridge. Since (b) is bad, you then have to spend a lot of time planning the routes for the tanks, and making sure the tanks have the right air cover, etc etc, i.e. doing more work. More likely, however, is that the manager, who is not a structural engineer, sees a perfectly good bridge and orders the tanks across anyway, causing the loss of the bridge, the tanks, and the war.
It's not debt. It's just (at best) an incomplete solution or (at worst) a bad solution that fails at the worst possible moment - e.g. database collapses during registration for the largest event of the year.
Ah, but surely, if you build the lightweight solution for $1m, and acknowledge the increased costs of managing the problems that it doesn't solve, then thats fine? Sure, but that's not technical debt either! That is scoping: we (engineers + business) identify a workable solution that provides some business value. And then we do that well. When Cunningham, for example, talks about what to do about debt, e.g. YAGNI, these are all good ideas: scoping. But the term "debt" is incorrect in this case. The term "debt" will only ever get a team in trouble as it indicates that the team is unwilling to confront the actual problem as engineering, but only as a broken metaphor.
Re: How to approach and prioritize technical debt
#23Here's a few observations (after long time experience and involvement in research around technical debt): 1) It is impossible to avoid gathering technical debt. The code will deteriorate in one way or another. You need to prepare to fix it since you can't avoid it. 2) It is so extremely difficult to make a correct "risk assessment" on technical debt so you should avoid doing so at all. You will just end up arguing al…
Code doesn't deteriorate... Like we're talking about a banana growing spots or whatever... Code gets plastered over with features and abstraction layers, but that's an active process that we are complicit in doing. More germane for this discussion, technical debt was originally defined as a positive thing that you want to go get... It is the mismatch between our domain model and how our users think about the domain.…
Can you share where you found this definition of technical debt? I've honestly never heard it articulated this way before.
Re: How to approach and prioritize technical debt
#24The best way to deal with tech debt is to never use the term in the first place. Almost nobody really uses tech debt as a concept the way it was intended by Ward Cunningham. It seems mostly to be abused to absolve oneself or others of responsibilities. I or others didn’t make a mistake, it was just “tech debt”. Sounds much more benign like this. Like tech debt is inevitable, unavoidable and current issues could not h…
> The best way to deal with tech debt is to never use the term in the first place.
At the very least, give it a more specific name.
A Reforge article[0] that was shared here about a month ago[1] suggests these six categories:
- maintenance debt
- developer efficiency debt
- stability debt
- security debt
- technical product debt
- decision debt
Re: How to approach and prioritize technical debt
#25Debt would be if someone said "I need to build a bridge across here that can handle an Army, and I've got $1m", we engineers reply "It will take $2m", and they respond "Ok, I will borrow $1m so you can build the bridge I need". Instead what happens is they say "Well, build what you can for $1m", and you say "Ok, we can make 'a bridge' for that", and then either (a) your infantry can cross, but the tanks have to get d…
What you describe is not what I've experienced with debt. Usually it is a conflict where short term goals and long term goals are at odds with each other. Using your bridge analogy, its more like "We only need an infantry bridge right now, but we know that in a year we need to support tanks". Well we can either spend $2m to build the tank bridge now, or we can spend $1m today for the infantry, but in a year you'll have to spend another $1.5m to make modifications to support tanks.
The debt there is knowing that "we will spend $500k more doing it this way (interest) but we will benefit in the meantime".
There are other factors too that make the true cost of the debt higher. For instance less flexibility as requirements change. I often find myself saying "this would be an easy change if we had initially built it in the more extensible way, but at the time you didn't need/want for extensibility so now your easy feature is actually a large refactor"
Re: How to approach and prioritize technical debt
#26It is true that the intention of tech debt is supposed to be when you make a conscious choice to take a shortcut now knowing that you will pay interest later and that other people use it to mean anything suboptimal whether due to lack of skill or changing requirements but in many ways the OP article stands for all of it anyway. Defects, tech debt, refactors, whatever you want to call them need to be measured against…
From what I've seen, there are three big schools with technical debt (past choices that now make changes difficult):
1) Ignore it and gradually ossify as the code congeals and it becomes harder and harder to make any change at all.
2) Assign a fixed budget of time, e.g. 20%, to refactoring and bugfixing and updating models and "moving to the new version of the language/library which lets us ...".
3) Prioritise the engineering tidy-ups alongside features. This involves (a) being able to credibly estimate the effort and value in the same dimensions as feature work is estimated and prioritised; (b) the people who do the prioritisation believing that engineering-desired work is as necessary as sales-desired or PM-desired work.
That last route requires people's beliefs and abilities to align. The middle route bypasses the entire prioritisation conflict at the cost of sometimes working too much or too little on technical debt. I think that's why you see a lot of fixed budgets for internal work.
Re: How to approach and prioritize technical debt
#27Here's a few observations (after long time experience and involvement in research around technical debt): 1) It is impossible to avoid gathering technical debt. The code will deteriorate in one way or another. You need to prepare to fix it since you can't avoid it. 2) It is so extremely difficult to make a correct "risk assessment" on technical debt so you should avoid doing so at all. You will just end up arguing al…
Code doesn't deteriorate... Like we're talking about a banana growing spots or whatever... Code gets plastered over with features and abstraction layers, but that's an active process that we are complicit in doing. More germane for this discussion, technical debt was originally defined as a positive thing that you want to go get... It is the mismatch between our domain model and how our users think about the domain.…
> Code doesn't deteriorate
Your specific codebase may not, but the frameworks, OS, and hardware it's running on evolves and changes overtime. Software practices change over time as we find more effective ways (hopefully) to do things. If you expect to let code sit and come back to it in 10 years and think that everything will be hunky-dory, I've got a bridge to sell you.
> It is the mismatch between our domain model and how our users think about the domain.
...but the business domain continues to evolve. A new client comes in, another software system is onboarded, the organization is restructured, new regulations are inacted that need compliance. I think the idea that technical debt only exists because we didn't "perfectly match" the domain and our model at the start is a bit short sighted.
> But at some point it started to mean that we had to upgrade our dependencies, that's tech debt, or this kludge that I threw in, that's tech debt
The broadest definition of technical debt that I've seen boils down to technical challenges that impede developer progress that does not have direct concern to the business. One of the reasons that I think that it frames a purely technical issue (i.e how the debt got there and how it needs to be resolved) with something that the business wants (rapid development). While there are a multitude of challenges in resolving technical debt, a significant one is getting the business to allocate time to resolve it. In order to do so, there needs to be some value for the business, not just the developers.
>More broadly, anything that we no longer care for is tech debt. And that's where you really get this idea that it is deteriorating, that's more a measure of our own patience deteriorating, especially as we never seem to have time for the refactors we want.
If you're defining technical debt as "anything you don't like", then you don't have a real understanding of your technical debt. One of the key pieces in the broad definition above is that the debt "impedes developer progress". Old code bases have plenty of things that modern developers don't like, but it works and it doesn't impact the application overall. It's old, but we barely touch it, so it's age or style is of little consequence. If you don't know what technical issues are causing signficant issues for your team or your codebase, then there's little justification for "paying it off". If you can sell the business on it, then you tend to get into long refactoring projects that provide little value than inflating developer egos.
Re: How to approach and prioritize technical debt
#28Here's a few observations (after long time experience and involvement in research around technical debt): 1) It is impossible to avoid gathering technical debt. The code will deteriorate in one way or another. You need to prepare to fix it since you can't avoid it. 2) It is so extremely difficult to make a correct "risk assessment" on technical debt so you should avoid doing so at all. You will just end up arguing al…
> The code will deteriorate in one way or another. You need to prepare to fix it since you can't avoid it.
Lehman's laws of software evolution 1 and 2:
"A system must be continually adapted or it becomes progressively less satisfactory. As a system evolves, its complexity increases unless work is done to maintain or reduce it."
Re: How to approach and prioritize technical debt
#29One thing I've had a lot of success with as I help early to mid stage (usually YC) startups try to tune things is empowering engineering by giving bizdev and stakeholders the understanding and expectation that ~25% of eng's time should be spent on things like writing tests, refactoring, and otherwise reducing tech debt. Putting a focus on reducing tech debt up front via CI, automated testing (including both unit and integration tests), coding style guidelines, CI checks for all of the above, etc., and giving engineering the time to attend to these issues and practices has turned around many flailing or failing startups that I've consulted with and/or provided advice to. The ones that do fail are usually the ones that resist addressing tech debt in favor of shipping more features. In truth, it is usually quite possible to do both at the same time, and it is in the very least possible to tackle new features in a way that doesn't increase tech debt at the previous bad rate through updated automated testing and CI requirements that ensure new features are fully tested before they are merged.
The hardest thing, especially with non-technical founders, is getting them to understand that yes, their precious features need to be pushed back a bit, but that this will prevent major issues, downtime, and slowdowns next quarter or next year, and that issues they are experiencing now are often due to neglecting tech debt in the past. Once they get this, the company usually has a much better outlook.
This is also an investing criteria (what is your ongoing plan to reduce technical debt) for some of the better tech investors, I've heard.
Re: How to approach and prioritize technical debt
#30Earlier quoted context omitted.
Code doesn't deteriorate... Like we're talking about a banana growing spots or whatever... Code gets plastered over with features and abstraction layers, but that's an active process that we are complicit in doing. More germane for this discussion, technical debt was originally defined as a positive thing that you want to go get... It is the mismatch between our domain model and how our users think about the domain.…
Can you share where you found this definition of technical debt? I've honestly never heard it articulated this way before.
> Another, more serious pitfall is the failure to consolidate. Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise.
http://c2.com/doc/oopsla92.html
Technical debt is only "positive" in the sense that it may permit shipping something now or earlier, but it accumulates and becomes something that can slow the project team down to a crawl, or worse totally stall forward progress. In the end, unless your project can be thrown away, it's a negative.