Technical Debt Doesn’t Exist
thehftguy.com
thehftguy.com
The explanation goes like this:
If you have no debt, you can borrow money.
If you have a bit of debt, you can borrow money, but you have to make regular repayments of maintenance to service that debt.
...but when you have a lot of debt, lenders are cautious about lending you money. Will you pay it back? Why didn’t you pay back any of your other debts? Can you afford the repayments?
The metaphor isn’t perfect, but the point being made is that maintenance is the repayments on technical debt; if ignore it, at some point you are going to end up spending all your developer hours on maintenance, and your throughput for features will grind to a halt.
You “repay” the technical debt by fixing stuff that causes problems, not by randomly rewriting it because you can’t be bothered reading the existing source code.
It’s not maintenance.
That’s a different thing; that’s making changes.
Technical debt is more like a metric of how prone to failure /what feature velocity your software is / has.
Sure, the metaphor falls over; you can just keep slapping broken features and other crap on top of either other indefinitely if you dont care if your existing features work or not... but, that’s a different issue.
This should be a cautious decision (and I’ve seen it happen many times, at individual/team/even org level). This is “tech debt”, and it does exist.
in an ideal world, yeah, that would be the cause, but in reality there are multiple other constraints:
- time constraint: you can not spend as much time as you want to make the perfect code (and that is ok, you want to ship and add value to the business so you continue to get your salary - see the extreme case of Duke Nukem Forever)
- dependency constraint: sometimes other teams requirement will affect your code quality
- cost constraint: again, you don’t want to go bankrupt
- competency constraint: there are juniors and there are people who don’t have the knowledge to perfectly cover your requirements
etc
That does not mean technical dept is not a thing or not a real issue in certain codebases.
Almost every day I think about the potential technical dept of my code.
It totally makes sense to take on technical debt in order to get your MVP out the door quickly; or to be able to fix an urgent customer issue; or to be able to make a release. And in some cases, it may make sense to keep technical debt around indefinitely.
What doesn't make sense is to pile on technical debt for no real benefit, and then not take any time to pay it down. That's like always buying things on your credit card just because you can and only making the minimum payments.
This is the wrong way to describe and explain technical debt. It fails primarily to sell the wrong idea that technical debt results from incompetence or failure to do a good job.
The truth if the matter is that in software development the absolute best solution to a problem is to provide an implementation that meets current requirements and is implemented as fast as possible. Overgeneralizing is bad code. Abstracting implementation details is a code smell. Proposing an implementation that considers additional design requirements and constraints is goldplating a solution, thus the sign of a mix of incompetence and wasted effort.
But then what if requirements change? Ah, the delta between the fast and good solution for the initial problem and adapting it with quick fixes to address the new requirements is precisely where technical debt pops up.
That's a separate issue from technical debt because whether code is generalized is only one aspect of many that determines whether the code is a dream or a nightmare to work with.
For example, if all your variable and function names are vague and misleading because you didn't take the time to choose names that make any sense, that saved you time now and will cost you later, but it has nothing to do with generalization.
That's one of the problems attributed to goldplating and over-engineering solutions. One man's future-proof implementation is another man's unnecessary indirection that's a problem to maintain. Thus we end up creating an environment where rigid implementations that are prone to colossal amounts of technical debt are preferred over adaptable solutions that minimize or eliminate technical debt.
- competent programmers who do a good job write the best code in the shortest amount of time
- more time always leads to worse code (unnecessary abstractions, handling non-existent requirements)
If you do know of programmers who are competent and generally do a good job, you can disprove this claim easily: Have them write a solution to some problem in a given amount of time, then have them spend more time on it.
Often you can see that they actually achieve a “cleaner” solution, including removing unnecessary abstractions.
I do agree with you though that some tech debt is caused by a lack of skills/experience. I guess we could further divide tech debt between intentional (the one I wrote about) and unintentional (the one you seemed to focus on in your comment).
As much as it pains me, this is an undisputed fact. If you get two developers to implement the same ticket and both hit the definition of done, but while one takes an afternoon the other takes two weeks, who performed better? That's the reality of today's corporate software dev culture. The best code possible is that which meets the definition of done and is delivered in the shortest amount of time and preferably requiring the minimum amount of changes possible.
> - more time always leads to worse code (unnecessary abstractions, handling non-existent requirements)
No, that's not a function of time. The problem I stated is that in today's corporate software dev culture goldplating and over-engineering are code smells. Thus the pressure is placed on adding code that is less robust and adaptable to change. Consequently, technical debt piles up whenever new requirements emerge because the current culture puts a pressure on "good enough, delivered as fast as possible". Refactoring and redesigning and cleaning up are deemed unproductive tasks that deliver no improvements or new features, and whoever delivers more features is deemed a more productive developer. Hence, today's software development practices favours accretion which results in continuously growing technical debt.
The faster dev may have skipped important things, things that can potentially sink the company, like security aspects.
The faster dev may have been aware of that and still decided it was worth to complete the task even if the system as a whole wouldn't be ready to production. For example so that the feature can be seen in action in an environment where for example security is not perceived as to be a severe risk factor.
By doing so, the developer plays with the definition of done, in a way that can be either advantageous or disastrous, depending on what happens down the line. Will product management understand that the system indeed still needs more work before shipping it to a wide audience?
This is where the debt metaphor has its teeth. It allows to negotiate these tradeoffs, also across the engineering team boundaries.
A small technical upset or failure can aggravate larger technical debt, not unlike a small financial upset or failure can amplify the threat of outstanding obligations.
Only the latter is usually visible and numerically measurable in any way.
In its ultimate form, technical debt is the liability that can cause bankruptcy of a technical company without ever showing up on the bottom line.
To put things on a level playing field and really bring it home, I agree with comparing your own solution after a rushed 2 days versus a full two-week completion of optimized code addressing the same issue.
>today's corporate software dev culture
Doesn't sound like it's good enough for NASA, but then again NASA doesn't have to worry about bankruptcy.
The shortest time possible to reach the moon was not accomplished using software taking the shortest amount of time to write & test to no end.
Google's tops in search now because of code they started on 20 years ago without ever giving up.
Not on what they accomplished last year, and especially not a 2-day sprint whether it has been deployed or not.
Technical debt does not have to reach its ultimate bankrupt conclusion for it to seriously dim your overall prospects.
Well, that sounds a lot like maintenance.
> The metaphor isn’t perfect
But there's a difference between maintenance that fixes problems expediently and maintenance that fixes problems more permanently. The technical debt metaphor is an attempt to model the cons of doing the former too often (otherwise faster always seems better).
That doesn't strike me as the main point of the metaphor. The more debt you have, the more borrowing becomes expensive because you have to pay interest on the total amount; it grows exponentially (in the literal meaning) if you don't repay it. As many find out the hard way, it gets to a point where adding new features or fixing bugs takes insane amounts of time because you can't make changes without breaking everything.
Good examples of this are premature microservices, no good separation between modules, bad database schema design, etc...
Software is not the end goal for most businesses, it's a tool to get
In all* the places I ‘ve done work for if there were any uncaught bugs during peer review we would be mortified (‘we’ being whichever person wrote the code) and endure a day or two of gentle ribbing from the rest of the team (sounds a bit like bullying but wasn’t).
If anything we (the team) shipped had bugs in it that were discovered during client demos or even worse at the end-user stage it would be like there had been a death in the family in the department for the rest of the day. And this was at all of the places I’ve chiseled code on to clay slates in cuneiform at (ok slight exaggeration there).
The point I am trying to (badly) make is - When did the attitude of ‘code fast, push it out the door and fix in v2’ become the norm?
I mean, sure in my days(), there was always a massive push by sales to get stuff out the door, screaming pre-sales consultants* etc but the Lead Dev would always be the one having sufficient authority (and guts?) to say - ‘it’s ready when it’s ready and not till then’. Diplomatically of course.
Perhaps the difference was in the way that project time-scales and milestones were set. We (the devs) would always double any time estimate and ‘fight hard’ to get bargained down to say 9 days down from the original ten (eg). Usually if it was ready by the 5 days it should have taken we would release it. All time budgets always included a full day allocated for the entire dev team to kick the tires on it prior to releasing anything.
Consultants and Sales guys loved us (dev team) – They get their ‘toy’ early so had a few days to play around with it before the customer got it (hint, makes for a much slicker sales pitch) but also because they knew we (any team I’ve worked with or lead) took any bugs very personally. If you have never been in sales, Trust me – the inner cringe a sales guy feels as the demo app crashes is a tough thing to recover from when pitching to clients.
Perhaps I just got lucky and never came across a company that moved fast and broke things. I’ve certainly politely never returned on day 2 at a few gigs based on team moral, coding style, basecode etc so who knows? Certainly I know that being able to mock competitors that released buggy code helped ease the pain of explaining why any stuff we did was 3x – 5x more expensive than the median of the ‘get three tenders’ quote price range.
Ranging from government departments, an international consultancy firm, an international high net worth private bank, small (10+ employees) companies, various start-ups (mostly B2B integrators, B2C arbitrage etc), NGOs etc.etc. After that moved to RTOS running on custom chip-sets and then some on to some other fun stuff. Mention not as a boast (hence the throw-away account) but to illustrate that the teams and companies I have worked for all had very, very different cultures and mindsets. If I had no experience of a start-up environment or experience of bureaucratic orgs etc then I really couldn’t / shouldn’t / wouldn’t comment.
* = when still junior enough for it to be an issue.
* (what are these days called Forward Deployed Software engineers I think)
All the smart things I ever read about technical debt basically describe debt and add the word "technical" - because that's what it is. It's not maintenance, it's not refactoring, it's just pure and simple debt.
Technical debt in software is unavoidable. Every variable and function and design decision can invariably be rebranded as technical debt soon enough.
The implication of "technical debt" is that there is a perfect state to reach with no debt, but there isn't. It also implies that debt could be avoided but it can't be, it's inherent to development.
"Repaying" technical debt is implementing the missing features, removing the temporary hacks etc.
Not taking it can be an option, if you have full funding upfront for example. It's just not always the best option. Just like borrowing money, getting into some technical debt can be worthwhile.
It is all about proper balance. Too little debt is inefficient, too much and you are getting overwhelmed.
The metaphor for piling crap on crap would be a Ponzi scheme. You pay your debts by making bigger debts. It works as long as you find suckers, it will break down eventually.
I was going to write that there's no reason you'd want financial debt qua financial debt, and that's sort of true but I realized that credit ratings complicate things. Sometimes an important part of what you're getting in exchange for the debt (and its repayment) is capacity for borrowing more when it first-order matters in the future, by way of establishing a reputation for being able to handle debt correctly.
Mapping this back to software seems interesting. I can't think of a parallel for credit reporting agencies, but it's certainly the case that a team might be more (or less) willing to take on technical debt to meet the schedule desired by a manager or a PM if there is a history of allowing them room to pay down the debt later (or failing to).
Under what circumstances?
What about https://en.wikipedia.org/wiki/Time_preference ?
Yes you actually do want debt because it is tax shield.
Technical debt, on the other hand, is quite literally a form of debt. You borrow time from the future by developing a solution that requires less work now, but that will need to be changed later on because it won't be enough future requisites, and that will create additional work (interest) in the long term while it's present. And every programmer does this, consciously or unconsciously. Say hard-coding some parameters in functions instead of creating user-defined options because it's easier, or writing a specific class instead of an abstract one that can be later extended, or writing a hack instead of refactoring so that new changes fit properly.
Of course, it's difficult to predict the future and some technical debt is never repaid. But it's important to make a distinction and to have in mind the technical debt in your project and when it's worth it to remove it.
I'd add that there is also a principle of not trying to predict the future and make design over-general and over-flexible 'just in case', but rather to have the simplest design that fits current requirements (though of course it should be clean and follow good practice).
The may lead to technical debt in the future but it may not. The idea being not to spend until you have to.
Now, a fudge now to save time should only be done under tight schedule with a plan to fix it later... In an ideal world. I think this is the case that really fits the analogy of borrowing/debt.
Overall, technical debt is unavoidable in a ever changing, unpredictable environment
That's the crux of why technical debt doesn't exist, or is not a receivable term. If it were debt there should be a way not to take it, but there isn't. Every variable and function and design decision will invariably be rebranded as technical debt by the next developer soon enough. That's not reasonable.
One solution to not have debt may be to not write anything, that's not receivable because then there would no product and no company.
The other implication is that there may be a perfect state to reach with no debt, but that's not the case, realistically it's not possible to start from code that's perfect and bug free and supports every (future) feature in the universe.
But can definitely be reduced. If my company plans on delivering version 1.0 with feature X, and version 2.0 with feature Y, I can either do an ad-hoc solution for X that will require less work but will need to be changed to allow Y in the future, or I can do some extra work now to reduce the total amount of work I need to do.
Those kind of decisions are made quite frequently while programming. Being conscious of them is important in order to understand better the project and the costs of maintenance and new features.
> Every variable and function and design decision will invariably be rebranded as technical debt by the next developer soon enough. That's not reasonable.
This is not a problem regarding the concept, it's a problem of the specific developer. Just because some people misuse a concept doesn't mean it's useless.
But you talk about technical debt as if it's necessarily bad. It's not bad. Some technical debt never needs to be repaid because the product is removed, or because that part is never touched and works well enough. Some technical debt generates so little extra work that it's worth it. But it's important to not scrub that concept, because, as I said, it's important to know the technical debt in a product so that we can better understand the costs of making changes and doing maintenance.
How does one go about promoting (fixing) technical debt, or ask for time to fix technical debt, or plan for technical debt in a roadmap or an end of year performance review. That doesn't work.
I do think companies and developers should drop the idea of debt entirely. Consider a more positive model where software development is a cycle to maintain and to extend. Maybe maintenance can put more emphasis on keeping things working and in good conditions.
I've worked for many years on many things from startup to finance to aerospace (this may include planes you fly in and the bank you use). Software is eating the world a bit more every day. The only consistent experience is how companies and developers have zero vision and incentive to keep software running smoothly. The closest thing is a recurrent mention of debt, more often than not as an excuse to refactor or throw away anything.
Saying that technical debt is made up is not a very productive approach. It's very real and programmers make the trade-off between less work now and less work in the future every day, sometimes consciously, sometimes unconsciously, sometimes because of lack of knowledge. It's useful to have a name for that and to understand it.
I've been programming for a few years already and being conscious of the concept of technical debt and when I incur on it when creating software helps me a lot by improving the decisions I make, by leaving better documentation on the technical debt used and possible fixes, and by being able to communicate better the risks and costs of certain approaches when deadlines are tight.
> How does one go about promoting (fixing) technical debt, or ask for time to fix technical debt, or plan for technical debt in a roadmap or an end of year performance review. That doesn't work.
I've done all these things.
- I've said multiple times to my superiors that implementing a certain feature in a short amount of time would add yet more debt to a certain part of a project, and that it might be better to invest more time to refactor code and add that feature with better code. That led to discussions on whether it was worth it or not depending on the possibilities of similar features being added. Sometimes we did the refactor, sometimes we did the hack. But we were conscious of the decision and the consequences.
- I've taken advantage of periods of low stress to ask for refactors instead of new features, arguing that those refactors would reduce future maintenance and development costs, or reduce bugs in certain fragile parts.
- When discussing roadmaps, I have explained that we can shorten certain stages with technical debt, at the cost of lengthening others to fix that debt, and we have discussed the trade-offs of both approaches.
In all of those situations, being conscious of technical debt allowed me to communicate better the costs associated with maintenance and development and enabled better discussions with management on what to do.
> Consider a more positive model where software development is a cycle to maintain and to extend. Maybe maintenance can put more emphasis on keeping things working and in good conditions.
I agree. That's why I think that the concept of technical debt, correctly used, leads to better understanding of the costs of maintenance and extension and enables better decisions.
> The only consistent experience is how companies and developers have zero vision and incentive to keep software running smoothly. The closest thing is a recurrent mention of debt, more often than not as an excuse to refactor or throw away anything.
But this is a management and culture problem, not a problem of concepts. I don't think that removing useful concepts from our toolbox fixes that. I think that the "not-invented-here" or "not-invented-by-me" syndromes predate the widespread understanding of technical debt.
But I think the analogy fits well when people either cut corners in order to save time now, especially, or, still, when people design something less generic now because there is no need to over-engineer things 'in case'.
The latter, and deciding on it, is a form of risk management. The former really is "borrow now/pay later".
Claiming that technical debt does not exist fails to try to understand the analogy, imho.
As a concrete example, a previous programmer at work when tasked with adding yet another file format to export would copy the entire code of one of the existing ones, make the necessary changes and ship it.
Instead he could have written it from scratch, recognized that "hey, I need to calculate the same sum as in this other exporter, let me refactor that into a separate function and call that" and so on. Then we wouldn't have two dozen pieces of code to check when doing maintenance.
Him not spending time to refactor created an additional burden that we now have to repay when performing maintenance, that's the technical dept.
It is all just a words game. If there is an issue now, and I do a hotfix and hardcode some stuff that surely will need work later on to keep things working, then:
A) I created technical debt. I took the quick route now, but will have to spend more time in the future if I want to update this code.
B) I did maintenance. A thing was not working and I made it work. This is a simple, small bugfix, a.k.a. maintenance. In the future we might have to spend some time to keep things working in slightly different conditions. We also call that maintenance.
Both ways of phrasing it can help to communicate a message. But there is no use in getting hung up on what to call it. Your job as a developer is to be smart about it and choose the best possible trade-off. You need to do that in both versions equally.
IMHO, part of being smart about it is having the words to communicate the concepts clearly, it's not a moot discussion.
Agreed.
> and technical debt unrelated to maintenance
Disgareed, as you cheerfully indicate yourself in your next sentence.
Technical debt as a concept of "debt" is paid back through maintenance.
What else might it be paid back with?
Technical debt it's literally dollars to donuts in time spent getting yourself out of the hole you are in right now.
Maintenance is the cost of keeping the lights on.
I run a two year old system which is now riddled with technical debt. How we got here has very little to do with the technology decision, stack, code, and a lot to do with management outsourcing and cost cutting.
Technical debt is never paid back through maintenance. It's just conceptionally wrong to tie them together. To phase better I can't maintenance my self out of this problem, but I can keep this system running forever with little to no cost.
IT is more than just development work.
Consider the cabling in a data center: It's very easy to create a new connection by dragging a cable down the aisle from one device to the other. But do this over and over and you'll be left with a tangled mess that's impossible to maintain, understand, and document.
Short quick fixes can be appropriate under the right circumstances, but it's important to go back and clean them up at the earliest opportunity.
Every builder comes in and says the previous guy didn't do it properly, used the wrong materials and overcharged.
Every software project I've been on, someone always comes in and says there's tons of technical debt, we're using the wrong language and the other developers are poor.
There's probably some truth in both statements but it takes experience and knowledge to take things with a pinch of salt.
Edit. This is genuine curiosity. I've made a slide out of software development into a more hands on role. I've found it rewarding.
They say that because it's true. Every project has a lot of technical debt.
Good technical management should understand the problems caused by the debt and prioritize it accordingly.
Bad technical management will devote no time to technical debt, and it will grow exponentially.
I do think technical debt does exist, though. Sometimes the changes that one wants to do are a bit too big to do right now and one should make a plan to get them done eventually and in small pieces wherever possible. This is called having architectural goals. One should try to be in this situation as little as possible, though.
The "technical debt" doesn't have a 100% universal agreement on what it means and apparently the author has only been exposed to one variation of it and that's what he's rebutting.
Another type of "debt" is caused by programmers writing bad/clunky code (often deliberately) to quickly solve a problem. The wikipedia article mostly talks about this definition of "debt"[1]. The programmers know the bad code will create "debt" that makes future maintenance harder. Example of this tension would be 2 different approaches to adding a feature or bug fix:
- (1) study the code base carefully -- maybe for hours or days -- and then write the properly architected code that makes future changes/extensions easy. E.g. expend the extra brainpower to see if the multiple edge cases or logic spread across files can be unified or simplified.
... or ...
- (2) quickly find the points in source code that seem "obvious" to modify just change it -- sometimes copy-pasting code and duplicating logic if if/then/else or switch/case statements in multiple files. Yes, now the immediate issue is "fixed" but you've simultaneously created "debt" down the road.
[1] https://en.wikipedia.org/wiki/Technical_debt
first sentence: Technical debt (also known as design debt[1] or code debt, but can be also related to other technical endeavors) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.[2]
I've always understood tech debt to be the shortcuts we take along the way to ship fast(er). A global variable here, a hardcoded constant there, that copy-pasted-slightly-modified function instead of adding a parameter.
Fixing those things seems qualitatively different from the maintenance examples.
No worries, we'll come back to it when we have more time (we never have more time).
There are only two priorities: priority one, and priority "we will actually never do this, because always something else will be priority one".
But of course, if it makes the engineers happy, we can put "fixing technical debt" in Jira, and assign it any priority between 2 and 99.
Software is a tool. Tools that are used often require maintenance, which in itself is not a novel concept.
Whereas saying 'technical debt' is like delivering a dramatically vague House MD diagnosis.
If you must, call it what it is – Maintenance – and let's move on.
Yes software is a tool, but unlike physical tools, it does not wear out. Running the same code many times won't cause it to slowly degrade.
What does happen with software is that as you adapt it to particular roles, if you're not careful you can make it very hard to re-adapt to new roles. A "new role" doesn't necessarily mean user-facing features. It can be as simple as running on Ubuntu instead of running on RHEL. Or it can involve using a newer (and incompatible) version of some library. It might even be as daunting as porting the software to a new language (eg: from JavaScript to TypeScript).
The common analogy used to illustrate this is that of a car. If you have a typical passenger car and you need to compete in a demolition derby, you can modify that car to be a good demolition derby car. But if you're then asked to modify that car to win a track race, you'll have an easier time starting with a new unmodified passenger car than modifying your demolition derby car.
Don't get me wrong, there are problems that mainly exist "in the heads of the engineers". Many of them want to refactor code or migrate to a newer framework or re-write for the latest buzzwords. But that's not technical debt.
In that context, maintenance is fixing your screwdriver. Technical debt is having a fixed-head screwdriver instead of another with swappable heads: it might be ok for you if you mainly use that one, but if you're constantly needing to buy new screwdrivers and carry them, it's extra money and work.
And the same as technical debt, you might decide to buy first a fixed -head screwdriver because you're not certain about your future needs and it's just cheaper and easier, and then switch to a swappable head when you are certain you need it.
Maintenance on the other hand is stewardship of a system as both the system(entropic decay) and it's environment constantly change.
Technical debt is a terrible term because it implies it’s just a technical problem, but it’s a business decision.
What the technical side of the operation wants to say is "We're making short term decision that are going to hurt us in the long term", and what the business side of the operation hears is "This is free money".
> Python 3 changed all the string handling, have to make adjustments. The build is too slow, should make it faster. Security vulnerability found in one library, time to update libraries.
is what (most?) people mean by technical debt.
If the build is just slow, but can be improved, that's not technical debt. Technical debt is when the build system is actually a bash script that was written ten years ago because none of the developers wanted to waste time on a proper makefile, and none of the interns knew make (or cmake, or ant, or whatever), and now just adding a new source file takes three hours.
(Edit: oh, or my favourite example, how could I forget this?
I've worked on a very large (MLoC) codebase that used autotools as a build system. Unfortunately, at some point, someone didn't want to learn m4 -- totally understandable -- and committed a manually-mangled configure script and a bunch of generated makefiles...
...and from that point, autotools were eschewed completely, and the configure script, and the generated makefiles, had mangled by hand each time something was required. Adding a new module to that program took 2-3 days of grepping and hunting through a bunch of files, just to make sure you didn't miss anything. That's more than enough time to learn the basics of how to use autotools. Multiply it by several hundred modules and weep.)
If a security vulnerability is found in a library, and that's solved with a library update, that's not technical debt. Technical debt is when message signing is done via MD5 hashes produced by a slightly buggy in-house implementation. You got to ship on time, but not by shipping a functional product -- that's a bug, and it still has to be fixed at some point.
If some stuff is single-threaded and slow, but easy enough to parallelize so that it's faster, that's not technical debt. Technical debt is when there's a single, global object containing absolutely all application state, and splitting an extra thread to do some computation in the background requires four weeks of extra manual testing just to be sure you didn't introduce another race condition.
(Edit: unfortunately, nope, none of the examples above were invented. I had the pleasure of working on a codebase where adding a new thread literally required written approval from the product manager because of the extra testing it required. Calling that "maintenance" is much like calling a bridge collapse a "vertical position readjustment" -- it gleefully ignores the fact that it was readjusted downwards, through gravity, possibly involving mass casualties, and had to be rebuilt).
Some maintenance work is legitimate and is just the result of normal software progress. But some maintenance work is entirely self-inflicted. Ignoring that is just an excuse for the kind of "first we do git push, then we think about it" crunch mentality that lots of companies encourage, for reasons that have absolutely nothing to do with either productivity or technical excellence.
We could go a bit further and start trying to categorise decisions by the different footprints of future maintenance effort that they cause. Roughly, we could differentiate between decisions that: (a) cause no additional effort in future, (b) cause a once-off impulse of additional maintenance effort in future, (c) cause an ongoing pattern of periodic maintenance effort in future, separately from any other change, (d) cause the effort required to make any other change in future to be amplified linearly, and (e) cause the effort required to make any other change in future to be amplified superlinearly. So now we've invented five somewhat arbitrary, non-exhaustive categories of maintenance effort to talk about [+].
Technical decisions that cause future maintenance effort of the form (a) are (relatively) fantastic, and (b) are often fine as well. (c) can become problematic depending on how often and how much effort regular maintenance has to be performed, but maybe can be dealt with by hiring an extra pair of hands to perform the activity. (d) and (e) will act as productivity dampeners and bog down any other development efforts, if they get out of control may completely prevent progress.
Technical debt issues of the form (e) might be: the system is built in a hand-rolled programming language that is not well defined, doesn't have specified behaviour or test cases, the developers are terrified of changing it but need to change it in order to make functional changes or fix defects in the system, but changing it tends to introduce more regressions that are discovered a few months later. Or maybe the code is arranged in an exponentially growing number of long-terms forks that need to exchange patches to support different special features sold to the latest key client, without good tooling support or test coverage. Or generally any system that's ended up in the state where the least-energy solution to fix any local problem makes the overall system globally worse, and for whatever reason no-one ever overcomes the energy barrier to do anything other than the locally easy globally corroding fix.
[+] We can define a lot more than five categories -- for simplicity let's assume we live in a world where it is not possible to make a technical decision that can ever _reduce_ the effort to make changes in future ("what if we migrated from using global variables, if expressions and goto to prefer using locals and structured programming constructs wherever practical") and act as a global productivity amplifier for all future development. Let's assume for simplicity that maintenance burdens are never probabilistic or conditional ("approach X will never require additional maintenance effort in future unless the client ambushes us with unlikely requirement R, which will invalidate the entire theoretical and practical foundations of X at the core of the product. it's a wager, most likely the debt won't ever be called in")
edit: i guess this could be characterised asymptotically with big-oh notation: "what's the asymptotic complexity of future maintenance effort introduced by this decision? as a function of t, time, or c, the cumulative number of changesets? O(0)? O(1)? O(t)? O(c)? O(c log c)?"
Although it is slightly wacky focusing on asymptotics of maintenance burden as the time or number of changeset goes to infinity, since in relatively finite timescales all the clients will defect or go bust, the product will fall out of use, the company will go bankrupt, the developers will quit or retire. hopefully someone remembers to ceremoniously burn all remaining copies of the source repository.
Things don't go from 1 minute to 3 hours overnight. The company and the developers had to work with it daily and didn't bother to take care of it at any point over 10 years. It's not a technical problem as much as it was an organizational and human problem. Inertia does add though so that's certainly difficult technically to replace now and getting more difficult by the day.
Technical debt is the additional maintenance for which you create a need when, presented with multiple options to implement a thing, you take the quickest and dirtiest one. It compounds the more you make decisions like that, just as compounding interest and capitalization create ever higher amounts of monetary debt.
Also, I found their self-referenced article on how Windows required more work than the pyramids, using man hours as a metric, simply absurd. This strikes me as a mythical man month type fallacy but can’t quite put my finger on it.
Good mechanic will refuse to touch your car. If breaks would fail after her fix, she might be liable.
Same apply to coders. If your code is bad, it will be very difficult to find good developer to fix it.
-- Technical debt is time that you have borrowed from the future. --
That makes perfectly good sense if you need a simple, working system, quickly.
But if you plan on extending it, then the workarounds and shortcuts that you took will need to be replaced, slowing you down in future. Concrete classes where abstractions will be needed in future, hard-coded values, all that stuff. The debt will have to be repaid.
I tend to work alone, so the poor schlub that needs to go in and maintain the code is usually Yours Truly.
That’s a big reason that I am pretty obsessed with heavily-documented code. I eat my own dog food.
It is quite painful to review undocumented codebases; even (especially) really well-written code. I write in Swift, and it’s entirely possible for an experienced Swift programmer to write highly efficient code that is almost completely inscrutable.
Not sure I’d necessarily call that “technical debt,” but it’s a real issue.
I’ve learned to use naive coding (in reality, highly efficient code often doesn’t buy squat), and a lot of “this is why I did this” commenting, along with long, descriptive entity names[0]; assuming that it’s my goal for my code to be maintained by others, and to not have them constantly pinging me with questions.
I will say that the (fairly ambitious) projects I’ve done that have grown into large community efforts, have resulted in very, very few questions about the code. It seems that understanding the code I write, isn’t an issue, for most people.
I write code for myself, and that seems to make others happy.
[0] https://medium.com/chrismarshallny/leaving-a-legacy-1c2ddb0c...
Refactoring is observably the best way to get to know someone's code. Refactoring doesn't have to actually change behaviour; in fact, the word itself means "improving the code without changing its behaviour".
Not seeing any value in this post outside of "I disagree with some words, let's use others".
Writing and changing code is a lot less boring than just reading it. Focusing on details (formatting, function naming, ordering, files) seems to be a lot more "gratifying" than trying to grasp the bigger picture.
I guess this is why I'll never become a senior developer / architect. Mind you, atm I don't have anyone else working on the same codebase either so it's all me.
At one point I decided for myself that I am senior by the virtue of being able to quickly understand what's happening in a codebase and where the real value-add lies, plus the ability to integrate it into the bigger ecosystem of deployments that the company practices. And having a good general culture.
So don't you care about "senior". :)
As for the topic -- harmless refactoring is indeed the way to get to know code. This has been said by people like Martin Fowler and Kent Beck so it's not exactly baseless and isn't easily refutable by a flaming post like the OP.
> Software do not have a technical debt problem, software simply requires maintenance.
Despite the words used, tech debt does exist. This article doesn't do much to make the task of maintaining software any better. It lumps it all together.
Tech debt, created accidentally or purposefully can be reduced with specific forms of maintenance which makes further changes easier and reducing future maintenance efforts.
I have experienced this and I also work with people who deny it. It's complicated.
Maybe you should try reading up on the subject matter next time before writing a blog post so you don't end up rediscovering fire again.
Not only that, it also compounds.
Each dependency adds a little more debt.
We have debt, we need to service it. Repayments come in the form of developer time. If our debt is well-serviced it enables us to keep up a nice quick pace of feature development.
If a feature is politically important and our tech-debt is under control we can fast-track its implementation knowing that we'll have time to polish it up later and it isn't likely to break too much.
If our debt is too high we can't borrow anymore. Sorry, that super important feature that the board wants by end of sprint simply can't be done. We're at our credit limit and if we try and borrow more to get that done we'll go bankrupt (the product crashes and burns).
All of this is the language of business
I think the only way to argue it was wholesale bad is that it immediately and objectively sank future progress (like a fatal wound of sorts). If it made things a hassle going forward, you'd have to argue that it was so much of a hassle that it actually receded things back into a negative. Most companies rarely experience the debt that stops forward progress cold or can prove they'd be making X times more progress if wasn't for such and such debt.
That said, if you could do things in such a way that yields the desired result and causes less (there is always some, and never little) maintenance, that's ideal. The thing is, everyone is trying to code from that place. The only ones who aren't are those who can't (they really are incompetent) or those who have given into utter malaise or malice.