I've also found that the term can be used to describe anything. Some folks would think of anything that isn't "shiny new framework" as tech debt. Some folks think of unsupported features as tech debt. Some folks think that the 2 million line monolithic code base producing billions of profit per year is tech debt.
After seeing a few too many tech debt reduction programs yield even more tech debt than they started with... I simply don't buy retrospective arguments any more. Decide what is acceptable/unacceptable at design time, don't strangle yourself on it after the fact.
Sorry, but I don't understand this. Tech debt it any mess that makes it harder to improve the product. You have to pay cost without getting any new value; the benefit for the cost was received previously. People may misuse the term, but it has a pretty clear meaning.
I also don't understand what "design time" could mean these days. 30 years ago, when release cycles were 18-36 months, it was a real thing. But now? With modern release cadences, we are always designing the system. Which is great, because the quality of design is limited by our knowledge, and our knowledge increases over time. Setting our standards early on in a project, when we're most ignorant, guarantees we'll be setting the bar wrong.
> Tech debt it any mess that makes it harder to improve the product.
Technical debt is absolutely NOT just "any mess that makes it harder to improve the product", not in its original formulation, and that's what GP comment is saying. Ward says directly, "A lot of bloggers at least have explained the debt metaphor and confused it, I think, with the idea that you could write code poorly with the intention of doing a good job later and thinking that that was the primary source of debt."[0]
Technical debt here, and in the linked article, refers to specific, intentional choices about features and behavior. I've taking to call thing formulation "Classic" or "Traditional" technical debt, to differentiate it from the more widely used definition that includes "any mess". In other words, a mess is not a Technical Debt, or as Andy Cleff says[1], "you don’t have Technical Debt – you have a mess, you have cruft: An unpleasant substance, the result of shoddy construction, redundant, old or improperly written code."
Cleff and I clearly agree that these things are all debt. And they're all in the technology implementation. I understand why Cleff wants a specific word for his sort of debt, and why he'd like to call tech debt. but I think that particular battle was lost more than a decade ago.
The reason is that it's pretty much irrelevant afterwards. If I need to work with some code but that will be slower because it needs to be cleaned up, I don't particularly care why it's a mess. I'm not going to indulge in corporate archaeology to figure out exactly what the intent is.
I also believe you're wrong about the linked article. For example: "Bringing that back to tech debt: a simple kind of high-interest short-term debt would be committing code without tests or documentation." Per Cleff, that isn't tech debt. (I suspect Ward would more flexible here.) But to this author and for the common usage, it is.
More useful to me, certainly. The debt metaphor is most useful when communicating with non-technical people who have at least some business/finance background, in that we need them to understand hidden "debt" in the technology, so that they make fewer bad choices about projects.
> Setting our standards early on in a project, when we're most ignorant, guarantees we'll be setting the bar wrong.
This seems like an artificial constraint, there are obvious basics such as
- Code should be reviewed by N people
- Testing should cover X core workflows/Y branches etc.
- Dev environments should be creatable in X minutes/hours/days
- The system should perform specific tasks (if you don't know what these are, then coding the system may or may not be the best use of time)
- The system should support Y TPS at Z cost (all systems have a maximum scale, estimate the scale that is required).
- Design should be signed off on by Y people, where Y may be 1 person in a small team.
etc. You can find the right set of constraints for your domain. However a system not doing something it wasn't designed for isn't really tech debt in my opinion, it's just a new use case which needs to be built for.
Sure, those are the obvious and common standards everyone needs. However they are mostly useless and easy to change if you get them wrong. The heart of how your code is designed needs to be got right up front and you don't generally know - yet - what it should look like.
I agree that we can take some stabs at some standards early on. Indeed, we should. But to think of them as then done and dusted for the life of the project is a big mistake. Indeed, I'll note that you left the variables variable for a reason. And you picked things that are extremely broad, applicable to any project. But the kinds of standards that go into deciding whether something is the correct design are generally much more specific to the language, to the frameworks, to the people involved.
aye - I kept things broad as ultimately circumstances are going to dictate a lot. The point is that it's important to decide these decisions prior to starting the project. I've seen more than a few engineers throw the term "tech debt" around as a justification for rewriting everything to their preference. Practically, these folks will often leave the organization prior to any meaningful benefit materializing from their work. This pattern is somewhat inevitable given the time to complete a successful full rewrite is ~2-3 years for a non-trivial application, and the time for an engineer to remain with an organization is on average 18-36 months.
There is a balance to all things, but I tend to only view tech debt as "work that we agreed that we needed but couldn't fund, and/or intentionally defered."
>The point is that it's important to decide these decisions prior to starting the project.
It really isn't. Again, that's when the least is known. I think a much better point to set a particular standard is when there's some sort of team disagreement that would be solved by setting a standard. At which point you'll have more information than you would have had before starting.
> I've seen more than a few engineers throw the term "tech debt" around as a justification for rewriting everything to their preference.
Sure, and that's bad. But it's bad because there's a dispute over the team definition of "good design" that needs to get resolved by the team. One way to avoid that becoming a massive problem is to regularly set/update design decisions as circumstances demand it. Because sticking with bad or out-of-date choices made before the project started is a good way to create the sort of tension and chaos where "rewrite it all in shiny new framework X" can seem like a good idea.
> It really isn't. Again, that's when the least is known. I think a much better point to set a particular standard is when there's some sort of team disagreement that would be solved by setting a standard. At which point you'll have more information than you would have had before starting.
This probably depends on the size of organization, and the likelihood that the product will survive long enough to require such revision. In my line(s) of work, the odds have been high and it's proven critical to make sure these points are clarified early. If the project is likely to be canned in 6 months anyway... then people can do whatever they want :)
While this stance is fundamentally Anti-Agile, I don't see this as a problem. While Agile's emphasis on rapid iteration is correct - my experience has been that folks forget the importance of testing a meaningful hypothesis or achieving a meaningful milestone in these iterations. In a vast number of domains, it's much easier and more effective to do detailed design work then jump straight into coding. The design process should hopefully land the team on the correct thing to build, how they are going to build it, and why they are building it.
I get it. People feel the pain correctly but decide the solution is some combination of write everything in shiny new framework and start linting more strictly.
After seeing a few too many tech debt reduction programs yield even more tech debt than they started with... I simply don't buy retrospective arguments any more. Decide what is acceptable/unacceptable at design time, don't strangle yourself on it after the fact.