I worked with Ward Cunningham for about a year, and he said once that he regretted coining the phrase “technical debt.” He said it allowed people to think of the debt in a bottomless way: once you’ve accumulated some, why not a little more? After all, the first little bit didn’t hurt us, did it?
The end result of this thinking is the feature factory, where a company only ever builds new features, usually to attract new customers. Necessary refactors are called “tech debt” and left to pile up. Yes, this is just another view of bad management, but still, Ward thought that the metaphor afforded it too easily.
He said he wished instead that he’d coined “opportunity,” as in, producing or consuming it. Good practices produce opportunity. Opportunity can then be consumed in order to meet certain short-term goals.
So it flips the baseline. Rather than having a baseline of quality then dipping below it into tech debt, you’d produce opportunity to put you above the baseline. Once you have this opportunity, you consume it to get back to baseline but not below.
I’m not convinced that the concept phrased thus would have the same traction. Still, I love this way of looking at it, like I love much of Ward’s POV on the world.
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.
Totally agree with that, but I don't think regret is warranted. The power of "technical debt" is that it was actually catchy enough to get a foothold with the MBAs and pointy hairs. That alone is a victory. Any sufficiently good idea with a catchy meme is subject to cargo culting and abuse. We need look no further than The Agile Manifesto to see how thoroughly any well-summarized wisdom, drawn from a well of deep expertise, lovingly word-smithed with the utmost clarity, can be abused and twisted into a hideous monstrosity that is, in fact, the complete opposite of the original intent.
Another problem with the analogy is that you can meaningfully make a $0.01 payment on your debt. You can pick any arbitrary percentage of your debt and pay it off right now, if you have the money to do so. Programming tasks are not only more (unpredictably) quantized than that, they're usually Sisyphean: if you do a little but don't finish, you've wasted the time you spent because the boulder rolls back down as soon as you stop pushing.
You can never make a $0.01 payment on any debt. You can try, but interest means your debt will grow faster than your payments! In the case of technical debt, interest is the recurring costs of working in the less than ideal code.
> I worked with Ward Cunningham for about a year, and he said once that he regretted coining the phrase “technical debt.” He said it allowed people to think of the debt in a bottomless way: once you’ve accumulated some, why not a little more? After all, the first little bit didn’t hurt us, did it?
I suspect that at the foundational level of this metaphor, the true problem is that some/most people treat financial debt the same, until they're evicted and the car has been repossessed and they've got a warrant out for their failure to show in court.
I want to be wrong about that. Someone tell me I'm wrong.
> He said it allowed people to think of the debt in a bottomless way: once you’ve accumulated some, why not a little more? After all, the first little bit didn’t hurt us, did it?
Isn't this exactly how people mismanage financial debt? If anything it shows the analogy is a good one.
> The end result of this thinking is the feature factory
I'm not sure how relevant this is, but a feature factory is the result of people contracting software development, and measuring it by features; nothing more.
Any other characteristic is a consequence, not a cause.
I don't believe contracting of any type us needed for a feature factory. It is more when product and project managers hijack the roadmap (or even create a roadmap at all) and then March along adding things for the sake of delivering story points, and the "it was _my_ team and _my_ vision that built this", rather than building on others work.
I think a good D&D analogy is your group needs a fighter. Instead of leveling up your decent level 6 fighter to level 7,8 and 9, instead you start multi classing, picking up some droid abilities cause, hey, surely it's cool
I believe you had the luck of never taking part on the extremely demoralizing exercise that is somebody deciding on the next steps for the software, writing it down and passing alone to somebody that will manage the development of that written thing; at the same side, some developers come, get the written down, non-negotiable decisions, and make their best on creating that stuff, fully aware that their continuing employment depends on satisfying the letter of those acceptance conditions, and the salary amount must be justified every time by delivering that in a market-competitive time.
In a feature factory, the developers do not get to know if there is a roadmap or not. It's not of their concern, and the competitive nature of the bids ensures that they won't have time to think about it anyway.
I don't think that this arrangement is even possible for hired developers.
Any delegation of work from one person to another involves a loss of context and distorts incentives. The only way out entirely is to build your own software to solve your own problems.
See the principal agent problem in economics.
Unfortunately subsistence software engineering isn’t a viable profession because the productive capacity of a single engineer is limited. And we occasionally need physical stuff like food/water.
Include in the contract "non-functional" requirements (the distinction can be fuzzy with a good case to put some requirement in both categories, but it's a useful distinction nonetheless). These are things like how stable it is (uptime requirements, perhaps), how secure it is. How quickly can a new feature be delivered? This lets you require an organizational capability, but not a system feature capability. If it takes your contractor 6 months to deliver an update with a color change to a page background, something is wrong. Require more responsiveness, but also offer more responsiveness on your side (like if you have a QA/test team responsible for final sign-off or to answer clarification questions, etc.).
You don't want to mandate their internal processes, at that point they're not contractors they're your employees and you are essentially taking over their management.
I am wary of formal offshoring of development at all. Contractors can solve a few problems for small companies when they are also small and you have a trusting long term relationship. On any other context, contracting seems to always fail.
But the specific format of specifying the software, contract it away, and pay for feature size leads to the specific kind of failure that we call "feature factory".
That's fantastic. I have been lucky enough to cross paths with Ward Cunningham a couple of times and I am always struck by his insight.
Kellan Elliot-McCrae has a similar take on technical debt. In his view there is very little technical debt as traditionally defined - an intentional decision to take a shortcut now that we remediate later.
Instead, "tech debt" is typically a label applied to code that makes developers sad because it resists change. Kellan breaks it down further in this article.
Don't forget people use ambiguity as a tool all the time.
Politicians use words like "justice" or "freedom" to create common ground with little controversy even when they define the term in a way diametrically opposed to their constituents.
I think it can be the same with "tech debt".
I have a friend who figures when he sells his house it will be a tear-down, so he has all kinds of "house tech debt" that he just manages to live with until he literally moves on. it basically means "I don't care about fixing that" or "I'm not going to fix that ever".
I agree with the author of the article that the metaphor is actually very fitting.
That said, I think Ward Cunningham's view is also correct in the context of how debt is viewed today. That said, historically, debt has been regarded as something which was bad for the borrower and only good for the lender.
The distortion likely came about because of reserve bank near-0% interest rate policies enabled by unlimited 'money printing'. Once reserve banks started offering near-0% interest rate loans, private banks found that they could still make big profits by making loans to people on very low margins like 2% to 5% interest rates (since they could themselves borrow upstream at 0%)... But these rates are impossibly low if you think about it. Would any private citizen in their right mind loan their own hard-earned money to other people for 5% interest per year? Let alone while knowing that inflation is almost 5%? Even ignoring inflation which entirely cancels out all the profit, nominally, it barely even covers the risk of the borrower stealing the money and leaving the country... Today, private lending doesn't make sense from the lender's perspective, even when you ignore inflation. Direct lending of one's own money today only makes sense for very risky short term loans with unethically high interest rates (loan sharks).
Anyway, to get back to the point; low interest rates brought on by reserve bank manipulation are unnatural; they made the deal unnaturally good for the borrower (at the expense of the average citizen). Historically, debt was in fact correctly perceived as dangerous for the borrower.
The point where the analogy breaks in theory and practice is this combined with the mythical man-month:
> That feels unexpected. If we're doing so well, why would we want to take on more tech debt? But think of it this way: if your product (thus company) are really growing that fast, you will have more people to pay down the tech debt next year than you do now.
Technical uncovered short position. Nothing wrong with taking a short position on a technical aspect of the project/product and taking the premium right now - so long as you hedge your bets. Otherwise you might have the contract assigned and go bankrupt, or fail to deliver the asset promised and lose everything. There's a reason purposefully taking uncovered short positions is illegal in most developed markets...
The end result of this thinking is the feature factory, where a company only ever builds new features, usually to attract new customers. Necessary refactors are called “tech debt” and left to pile up. Yes, this is just another view of bad management, but still, Ward thought that the metaphor afforded it too easily.
He said he wished instead that he’d coined “opportunity,” as in, producing or consuming it. Good practices produce opportunity. Opportunity can then be consumed in order to meet certain short-term goals.
So it flips the baseline. Rather than having a baseline of quality then dipping below it into tech debt, you’d produce opportunity to put you above the baseline. Once you have this opportunity, you consume it to get back to baseline but not below.
I’m not convinced that the concept phrased thus would have the same traction. Still, I love this way of looking at it, like I love much of Ward’s POV on the world.