But yes having people with the competence to actually understand the clear cut issues also making the prioritization would be nice.
And maybe we should not let people decide priorities who don’t understand the problems at hand and the trade-off to be made.
Bad code is something that happens, even to good devs. Sometimes you just don't have a clear picture of the problem and cobble something together to try and learn how to approach it. That code will be bad, but it was useful for its purpose.
It only becomes debt when faced with the results of your past mistakes you choose short term gains over long term profit, i.e. you know the code is shit but you keep building on it instead of dedicating time to refactor things because you need a feature yesterday instead of tomorrow.
Often this last decision comes from management, not the engineer that figure out things aren't going well.
It was about building software with the specific goal as to learn about the problem domain and the concepts. It is focused on high-level architecture, understanding and discovering the foundational structure.
And once you gain new insights NOT reworking code to align with new insights would result in ‘real’ technical debt.
There's no such thing as a prototype in practice, unfortunately from my experience. If management sees something half working then they don't want to toss it out.
These days the concept of technical debt has simply expanded to all other situations where this tradeoff occurs, where the knowledge is already partially there but the decision to go with the "prototype" (which is not a prototype because it's already known to be a dead end) is still made.
TL;DR: Tech debt occurs any time you write throwaway code to achieve some short term result, which you don't clean up later (pay the debt). Ward Cunningham's original definition is an instance of this more general definition, his is unnecessarily specific IMO.
It was about building something to gain understanding of the problem space and deliberately taking the time to incorporate new insights into the code. Not doing so would make adding functionality more difficult long-term. Obviously not incorporating such learning can be seen as a short-term objective, but it is more about being actually aware that you need some time incorporating lessons learned or otherwise there are consequences.
Your definition of technical debt is just making trade-offs and that just is that: explaining the actual trade-off and there is no need to talk about technical debt. It’s just a bullshit empty label.
> Obviously not incorporating such learning can be seen as a short-term objective, but it is more about being actually aware that you need some time incorporating lessons learned or otherwise there are consequences.
Why would someone take the time to do a learning activity and then not only ignore the results of said activity but actually deliver the knowingly bad attempt? The important part is why someone would do this, the motive.
There is only one reason to do so: they don't want to spend the time and or resources, or need to spend them somewhere else. That's a trade-off of course, so technical debt always involves making a trade-off, even in Wards definition.
I also vehemently disagree it is an empty label, it describes quite nicely the concern through analogy: paying interest (slowing down development) on debt (throwaway code that was kept). There are other trade-offs that are nothing like this.
However what people did is ignore his actual point and ran with the ‘debt’ analogy and now we call ‘not applying patches for a year’ technical debt whereas this is clearly just bullshit.
And for more serious topic, every trade-off somehow gets called TD. Every deviation from some platonic ideal is TD.
It just is extremely unhelpful for any meaningful discussion.
Also, I think that some decisions are to be made within the development team. It is not for the business to tell them how to develop and keep the code base healthy. Some thing you just do and they are just cost of doing business.
Business wants features and never wants to say, ok do maintenance tasks for a month. I’ve seen it play out, a lack of critical maintenance imposed by product caused days of expensive outages across multiple customers.
Thanks for being my sounding board :)
But the rest of the world has taken the concept of TD and warped it to mean ‘my fuckup with a more neutral label’.
Check definitions when you talk about TD with someone.
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
Really the concept doesn’t add anything.
Are we talking about mistakes?
Suppose that I build a system that has capacity 1M when the usage is 100 and growing at 10% a month. That system will be inadequate eventually, but it won't be for some time.
Should I have built a system with capacity 10M instead? Would it have been horrible if I'd only built for 100k. (It's unclear why those 10xs are different.) Should I have built a system with "infinite" capacity? Does the answer depend on how much each alternative costs?
If stakeholders are aware of design decisions and related cost + understand the potential trade-off, that’s it.
No need to add concepts like technical debt. And this example would not even be technical debt according to Ward Cunningham’s definition.
While Ward Cunningham may have introduced the term, his definition is obviously not the one that most people use, so it's pretty irrelevant.
However, I feel there is a need for an iterate approuch when programming, and I would very much call not going back fixing stuff accruing technical debt. No matter if the fault is "OK" and part of the natural flow of programming or incompetence.
In practice, however, many developers work in a low trust environment where management is quick to bring out the stick for any (perceived) mistake or error. In that scenario, it's understandable to not want to expose your mistakes.
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 have been prevented. Yeah, sure.
When I hear people talk about tech debt, my bullshit meter is immediately on high sensitivity.
I fully understand why people don’t want to expose their own mistakes or those of others. But I think it kills trust for those who see right through it.
Having to talk about tech debt instead of the real, actual issues feels emotionally immature. I mean this in a kind way, but I mean it. It results in this whole cottage industry dealing with tech dept, in a similar vein as the Agile industry.
I don’t think all this dressing up of rather clear cut issues as tech debt adds any value and only creates a layer of bullshit work.
I think we need less bullshit and more environments where people can openly admit to and discuss mistakes without immediately being raked over the coals / attacked.