We sound like idiots when we talk about technical debt
cyclic.sh
cyclic.sh
Technical debt is something that 'business users' don't need to or want to care about.
If you're having conversations about technical debt, you've messed up, and you will continue to have unsatisfactory outcomes until you stop doing so.
You can't tell people; here is a dial, you can pick 'fast and you're screwed later' or 'slow and careful now'. You're setting yourself up for failure; they cannot pick 'slow and careful', because that's not their job; their job is to quickly deliver value/outcomes/whatever.
Almost no one has a job of 'go do this really slowly and carefully'.
They will always pick fast, and it's your problem later.
So... don't do that. Instead, say: this is how long it will take to do.
Not "if we rush we could probably do it in..."; no, if you say that, then why are you not rushing now? Do you not care what the business wants? Do you not have 'skin in the game'?
Say: This is how long it will take, we estimate. If you want it faster, we can cut some features.
Then, do enough of a good job so you can continue to deliver value in the future.
That's literally your job.
Doing a rubbish job as quickly as you can is not your job. Not ever.
You cannot abrogate responsibility for doing your job properly by saying "but I was told to do this", if you literally gave them the choice of A or B, where one of those options was "you have to pick this one, and it lets me get away with doing a rubbish job of it".
That's YOU choosing to do a rubbish job.
...and to be fair, yeah, there are situations where someone will come and tell you "no, do it now", and that's what you have to do... but you also have to come and clean up afterwards. Not because you're told to, explicitly, because... it's your job.
Sure you can say that it's not possible. Then you get replaced by someone who's willing to take the necessary shortcuts.
What's important is to make it clear that you're taking shortcuts and that you will need time allocated to clean it up later. That's basically what technical debt is.
...it's not that easy. It's not easy.
I'm not saying it's easy.
I'm saying: If you do the easy thing, which is always choosing to leave technical debt behind, and waiting for someone to come and tell you its ok to deal with it... you're going to have bad long term outcomes in your project.
Part of your job, as an engineer / developer / whatever to spend a portion of your time not just doing work, but ensuring you can continue to deliver value in the future.
Here's a metaphor for you:
Some people like 'release based' branching; because you can push all your changes into develop (however messed up they are), and then some poor soul has to someone pull out a release candidate and then slave away over it to make sure it works...
You release seldom... but, most developers don't have to worry about it (just the release manager), and its fine.
Some people prefer trunk based development; it's harder.
Every merge to master you have to make sure your code actually works, because hey, it might go live in the next 2 hours.
A lot of people really hate this, because it means they have to do a lot of work and they cannot push the hard work onto someone else.
...do you see the metaphor?
I think it's pretty relevant.
Address technical debt slowly and continuously, not rarely and massively, and you will, in my opinion and experience, have better outcomes.
maybe you'll say, "requirements cant change!" on top of the earlier "deadlines should be reasonable!". IMHO that's fantasy, I've never worked on something where both these were true for 100% of a project
So even business users need to understand that there must be "maintenance phase" even for software, to pay tech debt, updating packages, patching / improving securities, etc.
I think the premise is that if you've got months of technical debt built up, you've already screwed up. If you (and everyone else on your team) refuse to ever take shortcuts, you'll end up debt free.
If you're already in a situation where you have mounds of debt, yes, you can't just increase your estimate for current tasks.
Besides, if your working style overly focuses on proper engineering while other things are on fire, the company could die.
The assumption seems to be that a single developer has agency and is aware of and solely responsible for everything that's going on in the codebase that they may or may not have written.
I've been in a situation where I joined a new company and the code base wasn't looking good but my job as a new hire wasn't to redesigh and rewrite the guts of it. My job was to implement new features, one after another, usually without enough specification to even begin to estimate how long it's going to take when everything they eventually turn out to want is accounted for. The project was already very late. I tried to spend time fixing the foundation and pointing out its problems (including complete lack of tests) but I was told to stop because the customer wasn't paying for that time. The problems I pointed out went ignored.. until they messed things up in production a couple years later.
I'm gonna say they chose rubbish against my advice, and they eventually got what they wanted. Rubbish on top of rubbish, with lots of bugs and slow development.
I've often told my boss the feature would be easy, but I would also like to take the time to clean up the code in the affected area since it's making it harder than it should be to implement changes. And I've gotten some time extra to do just that.
Other times I say doing it fast and cheap is possible, but I see an opportunity here to do something more clever and involved which will very likely open up further possibilities down the line. For example, I might predict other clients will need a similar feature, so by making my code a bit more general it should be easier to implement if they come asking for their variant.
Sometimes I get a green light on that, sometimes I do not.
I guess it helps that the owners are playing the long game, so my boss can afford to see beyond the next quarter.
Sometimes it's hard to tell your manager: Yes I know you want to track every single coding task in Jira, and you don't see any immediate value to this one, and I'm not going to dispute that, but I am going to do it and you "don't need to or want to care about it".
Sucks not to have that autonomy but it's real. That's when you have to justify the refactor, and not with potentially offensive statements like above.
When you're getting permission to do something like that, management is deciding if the risk/reward tradeoff is worth it, and I think it's only fair to give them the opportunity to make that analysis.
Person A: "Sorry, I can't do this because of X, Y and Z."
Person B: "Well, can't you do X, Y and Z another time instead? This is important."
You never really wanted X, Y and Z to be part of the conversation, but now they're in it and you've been placed on the defensive. If X, Y and Z were never mentioned in the first place, they wouldn't be on the table and you wouldn't have to justify them.
Same as it is with stuff like tech debt and non-functional requirements. You want to do them, you most likely have to do them, so bake them in. Keep the tech debt and NFRs off the table but leave the features open to negotiation.
Obviously has to be within reason if you want to maintain credibility, so you've got to figure out how to prioritise your tech debt too. And sometimes that means you don't do any of this and you accept a bit of interest on that debt.
Tradeoffs all the way down.
If their budget allows for that, then okay we go ahead.
I don't know about you but that is typically not at all how things go at my job.
I can present a 3 week estimate to manager, he will say why 3, seems like it should be easy??, Bob says it would take 2, can you provide a breakdown of the estimate, why does estimate have 3 days for "unforeseen obstacles"?, let's cut that out. We only have 2 weeks but we can't cut scope. 1 year later everything takes twice as long as it would in a cleaner design, management is wondering why dev productivity is low and won't allocate time to maintenance (we can't spend even MORE time on some refactor thingamajig, our productivity is already low!!). Meanwhile im trying to figure out some monstrosity of a codebase written by an engineer who left last year, and also neglected to document their code (unfortunately their manager felt 1 day for documentation was unnecessary). I think this is closer to the scenario most devs operate in. In all but the best high trust scenarios, every estimate is a negotiation.
In reality technical debt is 10% a communication problem (as this and many blogs like to frame it) and 90% a "do you trust your mechanic to have your best interests at heart" problem.
Your entire scenario would be moot if you practised scrum and estimated the work effort as a team. Your manager might get a vote, but that's it.
If you or your manager believe that there is only one "correct" option and that technical debt should always be minimized (vs being balanced against other factors), then odds are you're bother either terrible or very naive. In almost every moderately sized piece of work, there are multiple options and there's a choice of which one to take based on various priorities (ie, the best option varies depending on multiple factors).
Not to mention that some managers simply are adversarial, period. When you apply to a company, you can rarely choose your manager, and sometimes cannot work under a different manager without leaving the company entirely.
Tell Bob I wish him the best of luck in this endeavor, he's clearly a better programmer than I am.
Bob, and others like Bob who live to impress management with their personal 'agility', will implicitly feel more pressure to not go against the whole engineering team if you're able to reach even near-unanimity about what that strategy will look like, in this case, perhaps coming to agreement about how certain tasks will be pointed univocally, amongst other possible strategies. Your only obstacle at this point is a head of Engineering whose interested in their own career over and above his team.
Agile SCRUM exists, largely and for the most part in my experience, as an abuse to prevent this kind of 'collective bartering' on the part of Engineering.
There are always trade-offs, and a good partner in any team/business will help those be articulated.
One thing that is important for any engineering team is to have a certain amount of capacity either permanently dealing with technical debt, or regularly dealing with it. Judging the amount of effort that goes into fixing it depends entirely on the amount of 'interest' you're paying. That isn't always easy to measure, but a good senior engineering team will have a sense of when things are getting hairy.
The idea that it's avoidable is unfortunately wishful thinking for any project of a substance.
It also requires knowing the approximate amount of debt that may be involved in any given work. Or else actual work may far exceed estimates so often they become meaningless.
Estimates, as a rule, are never terribly accurate in the first place, often because of tech debt - adding in cleanup won't make them much better or worse. To give any kind of estimate in the first place, you need to be fairly familiar with the code, which includes the crufty bits that count as tech debt.
Hilarious. In the IT department(s) of my Fortune 150, they still do picture-perfect waterfall development, with outsourced teams, writing Java. The application is set in stone when it is signed off in production. Things change? NEW PROJECT. Another 3 YEAR CONTRACT please.
And, yes, as as matter of fact, it IS utterly maddening to be one of the few people who bother to try to say things could be different, and watching nothing change, because so many people's jobs are literally built on their world working this way.
So its not tech debt, its a complex system that takes longer to do things in future. "Bad tech debt" is like credit card debt, short term decisions made at expense of the future to impulsively satisfy immediate needs. "Requirements change over time but it was done right at the time" is like a mortgage and you need to move to a new town. Its entirely reasonable to have a slightly cumbersome payoff process because it was well chosen decisions. Still harder to pay off, and may incur more debt, but as long as its reasonable.
If you have a product that's nearing end of life and you can boost its value for another year with a quick hack, then do it. If there's a system that really needs refactoring and is getting harder to extend, but still works fine as it is, then you leave it alone. If things have gotten a little curly but are still serviceable, just roll with it. You don't just trash everything, obviously, but a year from now when you retire that codebase, any extra time spent on it now will be wasted.
In your new flagship product that you have no plans to replace for the next 5+ years, you take the extra time to keep everything nice. You re-engineer whatever needs re-engineering to add that feature like it was always meant to be there. You refactor the smelly bits of the code. You push back entropy to keep it shiny because it's likely to be worth it.
Unfortunately someone else IS willing to do a rubbish job as quickly as they can, look absolutely golden to their managers and clients for a while, then slingshot their career on to the next big pay raise, leaving the next poor chump to take the fall for their malfeasance.
Any organization where management does not readily acknowledge their reliance on technology and its associated upkeep costs is doomed to eventually sink waist deep in a tech mud pool of their own making.
Implementing a faster solution that will have costs later isn't me choosing to do a rubbish job. It's me helping my client make the best use of the available time/money.
When I hire a company to install a new heating system, they present me with various options; better/worse hardware, single/multiple zones, brand new hot air lines vs rewrapping existing vs using existing unchanged, etc. The person from the company may have a strong opinion on what is best, but listening to them and then making the decision I think is best is expected.
Would you pay for any of the options known to be unstable and will have to be replaced in a year?
What about the options that require HVAC staff to carry 24 hour pagers? When's the last time you got a whoopsie email from that manufacturer because of an outage?
- Installing a 3 port hot water line that has an extra, unused port for later (when we furnish the basement) and a cheaper, 2 port line. If we chose the 2 port line, it would have cost less now, but incurred additional cost (replacing it) when we furnished the basement.
- Using the old hot air lines (much lower cost, but less efficient), rewrapping the part of the current hot air lines that can be reached (middle cost, middle efficiency), and replacing the lines completely (higher cost, higher efficiency)
- Installing a reserve hot water tank (more expensive, but better able to handle load) or not (less cost, but could result in not enough hot water under load). If we went without the reserve tank and it turned out we were short on hot water on a regular basis, it would cost to add one in (overall, more than just including it at first).
None of those things are choosing between "doing a bad job" and "doing a good job". They are all a choice of how much we want to pay now vs debt we may/will need to pay off later. Ie, a parallel to technical debt. Technical debt doesn't always mean you did a shitty job, it could mean you took certain shortcuts because they accomplished what was needed _today_, but will incur additional cost _tomorrow_.
You'd better have Nostradamus-level prediction accuracy if you're going to play chicken like that with every estimate you're pressured to give.
That sounds a little crazy. If you applied this same argument to money, you'd conclude that their job is to spend money as fast as possible in order to deliver value, and the debt that builds up is accounting's problem, not theirs. No successful business works like this, so clearly the logic does work if it's presented correctly.
He would give me a task to do and would basically say "don't waste time making the code clean and nice" because he knew I had a software engineering background and didn't want me over engineering anything.
I would nod, implement it "the right way" anyway, and get it done in the same amount of time.
Because doing it the spaghetti code way always takes longer in the medium to long run, and often even the short run, anyway.
If my mechanic says my car has old parts not in inventory, they may cost more and take longer to replace or maybe they charge more to do the work.
When the laws change, your lawyer gets billed to review and update your contracts. As new legal precedents are formed, new legalese is created and updated and contracts are renegotiated.
Few things in the world are future proof for every conceivable externality. No one considers these professionals idiots simply because their domain has 'technical debt' too.
It us ok to have technical debt, to mention it, to bill to fix it, and to talk about it. And you only look like a fool if you try to cover it up and pretend it isn't there because 'its not the customers's problem'
- If the contractor finds asbestos *which was put in by the contractor himself because using asbestos was legal (and cheaper) up to 2 years ago"...
- If the mechanic that sold me my previously owned car without telling me that servicing would be more expensive in the future...
- If the lawyer who was originally part of the team that helped draft the old law...
etc.
- a developer takes a certain strategy that is no longer valid (even technical debt that isn't recognized early on as being something that will have to be changed more than likely soon, is still technical debt in my mind -- your ability to recognize technical debt early on just means you know you're incurring it)
- developers often incur technical debt without explaining to stakeholders about it because a) they don't care b) they don't think the stakeholders care c) they want to get the work done and not get dinged
- developers who have to pay for technical debt may be the creators of that debt to begin with...(of course, I'd wager that most technical debt is handled by someone else who comes later because I'm rarely given the chance to fix problems I created, project managers can be judgmental like that - and project managers have to be convinced that we can just apply some more duct tape)
Tech debt usually occurs when the people implementing it aren't aligned with the with the stakeholders.
Say you run a large plumbing company, and you discover your plumbers took shortcuts on a particular job that resulted in an abundance of leaks for a given project.
The plumbing company cannot ask the plumbers for their pay back. They will have to eat the cost and fix the plumbing.
So, it's the business's problem either way. They can additionally choose to fire those plumbers if they want, which is line with your point of not believing the plumbers had no idea.
But it's still the company's debt to pay. They made the mistake of hiring people that were not capable of surfacing risks.
Exactly the problem we always deal with: Business tends to distrust Tech because we always seem unable to stay on top of things we build ourselves
"There is never enough time to do it right, there is always time to do it twice"
Obviously someone* put that there. It didn't just install itself. Regardless of whether the contractor installed it themselves or not, the reality is it's there now and needs to be removed.
In other words, the analogy still holds regardless of "oh they put it there"
> - If the mechanic that sold me my previously owned car without telling me that servicing would be more expensive in the future...
That is exactly what every car dealership does with their "powertrain" warranties and service packages.
> - If the lawyer who was originally part of the team that helped draft the old law...
AAAAAAAHHHAHAHAHHHAHAAAA New to the legal system?
In any case my point is not "there is no tech debt if you created it yourself" it is more about "from the point of view of business tech debt is not something they care about: it is sonething they expect to just be sorted out transparently or that should not even happen". After all, Microsoft never bills them for "tech debt", it just ask them to reboot to update their laptops, no?
I am not saying this is fair, or right. I am just trying to explain why mentioning "tech debt" falls on deaf ears.
Modern SW practices don’t accidentally end up with technical debt, they’ve gotten to the point where they don’t even give limiting it a thought and will happily pull in mountains of other cider’s technical debt on top of their own.
Then a new house is also shown, but we are only shown mainly interiors and views, never an iota about how the foundation or technology of the house works. That bit you the last time. And the owners want to get rid of the old house because it left a bad taste in their mouth by having these "surprises". Yet they waltz right into the next one with no concern whatsoever. (The shows also never talk about costs of living.... it's just the buying price of the house.)
These things all have direct analogies in the software world. It very often feels like a lot of people in the business are interior decorators and if I try to converse them as a structural expert - it just doesn't work.
Ever had your boss tell you a feature needs to be delivered next week or the business closes? Or that you're fired?
I have in fact had my commits gleaned by my boss, told me "no, we're not shipping these 10 lines of code because that goes too far and not what I asked" and then refused to accept the pull request because he had control.
Just because YOU have never been in a situation where YOU didn't have control over the creation of technical debt doesn't mean its just some magical thing you can fix and change by saying the right words, don't be naive.
I just wanted to call out the posters who blame individual eng for the product quality, they've either never worked in a toxic org or are helping be the source!
Yeah, you can pass a proof of concept to the customer and they'll ask if it can do one more thing.. and then, tweak this a little.. and add this one little thing.. before you know it, your proof of concept is in production and they just want a little feature here and another there and they're not interested in having it written "properly."
Investing time making things clean is a bit tricky if the party you're supposed to bill for that time is not interested and you're not going to invest out of your own pocket.
Um, taking a day vs 3 days is huge. Because the cost of each task is now 300% of what it should be.
Time to market is also absolutely impacted by technical debt, for the same reasons.
Describing this to company leaders in ways they understand is pretty straight forward.
"If we take a week now to fix this problem, we will be able to do 3 times as much work in the same amount of time going forward."
Maybe delivering this feature in 3 days to the important client vs 8 days is important enough to put off the needed refactoring from a business perspective, or maybe not. But now the business leader has enough information to understand the tradeoff and make a decision.
I’d argue that technical debt that can be resolved in a week is not real technical debt.
And when you’re dealing with “real” technical debt, it’s hard to substitute numbers into that sentence without lying through your teeth. “It will probably take us a month to two months to fix this problem and in terms of product launches it’s completely ambiguous how much faster we’re going to be.” isn't nearly as easy of a sale.
Which indicates there really isn't much quantifiable value in the refactoring, and it's probably a poor use of developer time.
1. Technical founder-led companies which have enough technical understanding to have a realistic conversation with engineering leaders and make a decision as to how to approach the problem space to balance time to market vs quality of abstractions.
2. Developers with high autonomy who can set their own timelines as long as features are delivered in expected form. In this case, the timeline can simply encompass either resolving previous technical debt or be extended so that there is enough problem analysis time to prevent the accrual of technical debt in the first place, as long as the feature works as expected at the end, but it's on the developer to deliver to expectations that may not be fully defined. These are usually organizations where engineering has high political capital as department, but the larger business treats it as high magic.
There's a big difference between "this code is horrific and can't be built upon" vs "ugh, this framework is so old, we need to rewrite it in Foo.js".
Admit it or not, the reason you want the technical debt addressed is primarily emotional. You are frustrated with how difficult it is to work, you fear for the future of the project. If you want to compel someone in charge to make changes, you need to make them feel things are bad as well.
This is to be used responsibly, though. If it turns out you've convinced someone into acting in a way that is against their interest or a big waste of time, there will probably be blowback later.
It's perfectly rational to be concerned about these things. We are not machines - or rather, we are machines that have mental/psychological/monetary needs that have to be met in the course of our daily employment.
If you explain these logical steps to someone else, what you're doing is showing them that they too will likely be affected by what you're suffering, that is, showing them they have a reason to fear too.
A message's ability to provoke some form of action is entirely dependent on its ability to create some form of emotion, be it fear and indignation or hope and optimism. The most effective rhetoricians are exactly those that are very good at producing those feelings. From Hitler on one side as the archetypal rabble-rouser; to MLK on the other end of the spectrum, who created profound optimism and hope. It isn't because of their syllogisms that they were convincing rhetoricians.
Merely knowing a fact is rarely sufficient to provoke action, unless that knowledge itself creates an emotion (an idea can have aesthetic value, for example).
A VP of engineering pulled me aside after he saw that one of my proposals wasn’t getting traction and told me “None of the people who are writing alternatives to your proposal are doing the analysis you are, that’s why they look better than yours”
I guess I had never considered that a lot of my peers were just inventing numbers to justify things they wanted and that there’s a careful balance that needs to be struck between “making shit up” and “detailed unbiased analysis”
Let's say person A gives longer estimates but is accurate within 10% more than 95% of the time. Let's say person B gives estimates half as long, but the team runs over by 75% a quarter of the time and by 150% about half the time. Whose proposals should the stakeholders choose?
If your company is making decisions based on estimates, the accuracy trend on those estimates is a far more important metric than lines of code, number of commits, story points, or nearly any other metric they're keeping.
You're probably better off just playing the game and making up good sounding numbers. You're less likely to have half the company resenting you and making your life difficult.
Oh wow. Boy have I been bitten by that before :(
Business leaders have wisely learned how finances work, and financial debt. We need to learn how software engineering works, and technical debt. It's relatively new. Business has a long history, going back to the days of kings. Imagine a conversation with a king who hadn't learned about financial instruments.
King: We need to raise an army.
Duke: Okay, but we're out of money. We'd have to borrow more.
King: Are we able to borrow money for it?
Duke: Yes, but our debts are racking up, and there could be future consequences.
King: Sounds like we can borrow money, do it.
It would also better cover the fact that work must be done to get rid of the excess mass. Calling it debt might undersell how easy it is to get rid of it.
Though if business folks didn't take physics classes it might not resonate well with them.
Because we get so much of our tools essentially for free now (languages, operating systems, browsers, mobile clients) we have to accept that we don't control the pace of their development and deprecation. So maintenance must permanently adjust to an existing, moving ecosystem.
The thing is, I have never met a manager that budgeted this fromt he get go. But I also never met a manager that did not understand the sentence: "We won't be able to ship/develop after day X because big OSS project Y deprecated our version" (think CentOS repository deletion).
It is our job to keep an eye on this and report it in the terms management understands: "We use Y for free so we have no leverage and Y stops working on day X, stopping all our activities."
Product is pissed because delivery is stagnated and that's because of technical debt.
Product: We need that change for Big Co.
Techie: Okay, that takes two weeks.
Product: Two weeks? For such a small change??
Techie: Yes, because we are drowing in technical debt and you're priorizing features and not maintanence.
Also, usually techies don't care.
Why? Because it's always good to have an excuse to work slower.
Essentially the features, flows and output are fixed and defined, so you don't need to think about that. Your skills at performance optimization, refactoring, unit testing and debugging really shines here.
The average dev just does their job. Same as with the average person in every industry.
Sure, it's nice to do a cool feature, but most people don't work at interesting projects to start with, and they simply have to churn on. There isn't much difference between a new feature or maintenance in boring projects.
Yet the intro provides an example of clearly quantifying and communicating the costs. I'd say he disproves his own point in the introduction. I found it hard to read the rest of this article.
Oof. What's better is setting and going by your own pace and making sure you're projecting expectations with regard to that pace.
One cost of accruing tech debt is the toll that it has on the mental health of developers. To me, it seems like common sense that over a certain threshold, unhappy developers will (1) work slower, (2) produce lower quality work, and (3) have a higher rate of turnover. I’m curious if there is any research on this effect (if it exists).
Business began with a certain idea, then over time pivoted into into better and better, mostly related niches for users. What that meant in terms of the code base is we started with one thing then tried to back-port it in several new directions and ended up with a gigantic ball of spaghetti.
Great job, great coworkers, great technical management. Code base just became so rotted and so overextended, it became untenable.
Edit: clarification.
Agreed. But you’re using the term mental health as mutually exclusive to mental unhealth (unhealthiness?). I’m asking what the effect size is (assuming that there is an effect) and whether it can be modeled on a curve.
Edit: (addendum). It should go without saying that many people work in environments that are to some degree unhealthy for them and don’t have the luxury of switching.
My hot take (sorry) is that business people are actually more in tune with this fact because they deal with the more chaotic side of the business (clients, funding, competition, $$$ etc). So they are less willing to give developers the time to 'do it right' vs 'do it fast', since they believe that EVEN IF it's 'right' today, it probably won't be 'right' tomorrow and we'll have to rewrite/re-do/refactor to accommodate the new paradigm/circumstances.
Of course this catches up with the business since so much duct tape will inevitably slow new development; but then tech debt can be dealt with on those terms vs. "prepaying" the cost of fixing the future problem.
Accountants do not _ask permission_ to reconcile the books with the bank account. Mechanical engineers do not _ask permission_ to replace a part that is in danger of failure + could cause injury. Electricians do not _ask permission_ to use the right size of wire for a circuit.
Software engineers should not _ask permission_ to do the right thing. Some component of your software is fragile? Write tests for it. Difficult to add one more thing to that already tangled mess of spaghetti code? Untangle it. No idea how some part of the system works and there's no documentation? Figure it out and then _write documentation_. Security patches need to be applied? Apply them.
There is a balance to strike here of course: you still have to deliver things. Do refactors in small-ish increments if possible (don't just rewrite the entire system). Write a couple tests every time you change something. Whenever you have to ask a question about something, write down the answer. A product owner may not understand the importance of doing these things, but that is not something they need to give their input on. Code organization, testability, etc are not product features. They are engineering details - details which engineers are obligated to pay attention to.
The software profession has no such thing, for the most part. So clients will keep probing and meddling, just like toddlers who want to know how much they can get away with before their parents punish the misbehaviour. And if some people die, or suffer from algorithms gone wrong, or are just generally pissed off left and right because of bad software - who cares. Profits are king, right?
Simply do not entertain probing and meddling. "It's going to take a little longer because the software is complex and it takes some time to untangle it" is all you need to say. Whether you refactor/test/document it in the process of understanding it is irrelevant.
In a healthy team, engineers are responsible for the health of the system.
In a healthy team, engineers make decisions about non-product-feature related work, including tech debt. Product managers decide the relative priority of product changes. Engineering managers (who must be just as technical as the engineers on their team) make schedule decisions, balancing the health of the code base and the product needs.
Both financial and tech debt are trade offs between future and present, leveraging the latter in detriment of the former.
But financial debt is authorized by corporate finance, which is empowered to do so by the C-suite and implicitly by shareholders. Whereas technical debt is created at ones own risk by the Individual Contributor, who didn’t ask the shareholders if they liked the trade off.
The only reason it looks like debt is because it compounds, which is ironically something people don't really focus on when discussing it with management. People don't want to look incompetent so they say "Feature X took 3x as long as it should have, because we had some tech debt". It's implied that the tech debt is resolved. But in most cases the reality is, the time was spent just working around the tech debt, and the tech debt is not resolved. And now you've entrenched even more workarounds and hacks that will make things worse. Compound interest baby.
The truth is technical debt is a metaphor specifically designed to be understood by non-technical business people. Technical debt has gained traction as a concept because it does actually give a reasonable indication of the cost tradeoffs of short-term vs long-term implementation decisions that was formerly very difficult to explain.
Of course, all analogies are flawed, and the devil is always in the details. Over time "technical debt" has been used to describe all manner of problems which don't really fit the rubric as interpreted by a business person, for instance: changing requirements, UX debt, bitrot, junior coders, bad guesses about the future, etc.
What it boils down to is effective communication: the mental model of your audience, and your reputation. If you are in an org where there is no understanding of technical quality and no trust in engineering, then the assumption will always be that you're sandbagging, and frankly this is no place for an honest hard-working engineer to be. On the other hand, even if there is a strong engineering culture with a CTO who understands the details and has an equal voice at the table, you can't just cry "technical debt" at every turn because engineering is more complicated than that. There are usually paths to deliver value while improving quality over time, but sometimes it requires different kinds of pushback. Reframing the problem with alternate sequencing or 80/20 proposals to product or business stakeholders is often more fruitful than endless negotiations centered around resource numbers. However it all stems from trust. If you as an engineer or engineering manager can demonstrate you understand the needs of the business and can more efficiently transform engineer hours into business results, over time that gives you the reputation to be heard when it comes to long-term tradeoffs.
This line going up is inevitable and natural. The slope needs to be managed obviously. But the only way this line stays flat is if your company is failing.
I think the correct framing is that it should go up only with the logarithm of the code's age or size. If it's going any faster, you have a problem.
In order that you could say 'it's now taking us twice as long per complexity point as it was last year', and know that that was meaningful.
If they understand financial debt on a balance sheet and they understand schedules and Gantt charts, perhaps we should call technical debt what it really is to the business: temporal debt. Explain that because we've taken shortcuts in the past, we were literally borrowing time from the future, and that time balloons with interest until we pay it back.
If they startle at the mention of "tech", how are they not going to be startled with "temporal"?
Stop creating technical debt.
No one ever asked me why in particular something took 3 days. I don't explain to someone that I wrote unit tests and no manager told me not to write tests.
Did you ever got chewed out by a manager looking through your git commits and asking you why you wrote it as it is written?
If you accept technical debt it's the development teams fault.
And yes a not that clean feature, which is easy to refactor IF you touch it again is not technical debt.
Instead lern to talk back: "oh you promised our customer that this feature will be ready tomorrow? I'm seeing a big risk in this as there are still issues we haven't figured out, you might want to manage their expectation."
"Ah sry I can't work longer today I already have a reservation"
"On the weekend? Mh I booked a hotel already"
"How long this takes? Mh let's see (1 day guess + 100% risk + backupday) at least 3 days. I can get back to you in 2 days to give you an update."
"I can prioritize your new request but I will talk to x to tell him that his task will be delayed."
"Didn't you promise customer x feature y already? Should I stop working on y to start with your new request?"
I have a min. Standard I achieve and will not compromise this standard to keep me sane.
I will not create things which will fall back to me in 3 month.
I develop slower but have to revisit things rarely.
They're welcome to do that with their own code in their own time (and many people like to do that, quite understandably), but it's toxic in any sort of business environment. You need to be able to make practical judgements about how much time to invest in, say, an MVP feature with a 70% chance of being ditched.
I get the sense that everyone here is imagining their own - very different - concrete example of tech debt, and talking entirely at cross purposes as a result.
This is why I say it's fruitless to discuss this without making clear what concrete examples we're imagining when we say 'tech debt'. I'm almost certain that you and I are not thinking of remotely the same thing. 'Tech debt' is very different from plain old shitty code.
Why don't you "simply write code faster with fewer bugs" seems sarcastic or unrealistic (or Übermensch) but over time with practice we should attempt to do this. And I do see it, within the practices of the top software engineers on GitHub, who often write better quality code than I could faster than I could. It must be achievable.
Like I said here -> https://news.ycombinator.com/item?id=30286860, I think this whole thread is proving slightly unproductive because everyone has their own definition, and concrete example, of tech debt in mind - and so we're all talking at cross purposes about different things.
I suspect that lots of the stuff people seem to implicitly be talking about is not tech debt by my definition, but rather just shoddy code. That seems to be what your comment is talking about. If you can write a better implementation in the same time (subtracting time taken to learn about either implementation technique) then it's not tech debt AFAICS.
And that's just not so. It doesn't matter how fast or quick-minded the engineer is in absolute terms. I've worked with some of the best engineers in the world, and they still took on tech debt (albeit in an intelligent and considered way), because simpler solutions are still faster in relative terms.
Tech debt will forever be a rational choice so long as there's a comparative advantage - so to speak - in taking the simpler path.
When the latter is validated and becomes the former, that's when - and why - you repay your tech debt.
A team that builds everything as though it were a business-critical feature, which needs to be architected as safely as the control loop on a rocket, is a business which is pathologically unable to experiment and iterate.
Everything will find its way back to you.
Bugs are very costly.
I always make sure I für understand what the problem is. This can lead to me having discussions of 2-3 h and the outcome is that we actually don't need it. Or that we reduce the scope to deliver on time.
I'm not aware of things I write which will not bite me back one way or the other if I'm doing it shitty and having development standards is not developing a rocket.
But I will not build a sync feature and not having alerting if it fails.
I will not write nee Features and will not think about a proper index.
If you do it right and actually learn those things from an early point those things become obvious.
And yes there is also that believe that a bug in production costs 10x what it would cost to find while developing.
Yes I'm aware of the fallacy that a manager might praise you if you are fast and accepts bug as a common normal thing.
Tech debt is more, say, "let's build this new bookmarking functionality by saving bookmarks locally" and then, later on, "let's make it more extensible by syncing them with the server, so we can build on it by e.g. using this information in our new recommendation algorithm".
It's about implementing things in a less complex but less extensible way, and perhaps a less feature-rich way, so as to more quickly validate user demand and thus iterate more quickly.
And yes, it's trivially true that you'll be slower than you could be otherwise by not doing this. You might think you're still faster than other people will be. I wouldn't bet my own money on that, but it's your prerogative to bet yours.
I think our hypothetical company would likely founder on any of a hundred other issues before this one if none of the engineers had this skill.
1. Domain modeling shifts. Engineers get a sample of the business rules for the domain they're trying to model every time they build a feature, but it's an incomplete picture. And in fact sometimes the very nature of what the business is trying to accomplish changes. That can require fundamental shifts in how the problem is modeled.
2. Changes of scale. What was engineered to support 10,000 MAU will not necessarily tolerate 100M MAU. Scale can be insidious for tech debt because it's often a slower creep of a problem w/ a high cliff in the amount of effort required to solve for it.
3. Planning/communication failures. Sometimes a critical aspect of a feature is not fully understood or articulated. Or an important delivery date for a promise is overlooked. Depending on the nature of the company's business, an early stage company often doesn't have a choice but to deliver on things that weren't properly scheduled.
Alternatively, in companies where there are Product Managers or Engineering managers, those folks should be skilled at parsing, translating, and conveying the technical issues to management and stakeholders in financial terms they'll understand.
"We" the engineers don't sound like idiots - "we're" being literal, which is all "our" job typically requires of us. I see this as a failure of leadership rather than an individual-contributor problem.
- you said you fixed this problem but I'm still seeing it
- you fixed this problem but you created a new one
- we can't deploy a fix for this problem right away because we have to certify the whole monolithic mess first
- testing this fix takes an hour to coordinate
"if we invest around 3 months now then we will reduce the time to market of every subsequent feature by about 2x and also decrease the number of bugs each feature produces by about 70%"
Then make sure they understand that these are just approximate estimates, but it gets the idea and the urgency across.
They “need” to be on the latest version -> upgrading versions takes a long time and is prone to error -> the process would be infinitely easier with a robust test suite -> we never prioritized automated testing which is a tech debt which we are now paying interest on in the form of being on extremely old versions of a product.
It is critical that technical people have data to back up their claims that maintenance is needed. We need to identify exactly what each piece of tech debt is, how much work is needed to remediate it, and what the business cost of not remediating it is. Otherwise the business has literally zero idea what it will cost them not to do maintenance. This is an expected part of professional software engineering in a business. If you are not gathering this data and presenting it to leadership, do not expect them to take you seriously. It is up to you to prove your case.
"Technical Debt is really Software Debt. And it’s a AAA-rated CDO." https://www.evalapply.org/posts/software-debt
Context:
> I’ve long struggled with the Technical Debt metaphor. It was immediately useful when I first heard it. I still think it is useful, albeit as a starting point. The more I worked with software, the more infuriatingly incomplete it started to feel.
> One source of my unease is that I think discussions of Technical Debt don’t sufficiently examine the nature of the Risk of the underlying challenge. The other is that the concept skews and pigeonholes the Responsibility part of the underlying challenge.
(More at the post. And if I sound like an idiot in there, may I be an AAA-rated one. :)
Edit: add some context from the blog post.
Everything should be done as slow as possible as long as client isn't annoyed enough to change providers.
Business people both at your company and at Big Corp co customer benefit from keeping things as they are for as long as possible. They keep getting paid for as long as the project lasts. But when the project finishes, a lot can go wrong. It might turn out that it was completely unnecessary or that it doesn't solve the problem it was supposed to solve or that any given business person no longer has any utility for the respective companies. Basically a lot of trouble. So technical debt might be something business people actually silently treasure.
Even if we SWAG the percentages (which, guess what, financial-oriented people do all the time!), it lets Product Owners and Managers make better decisions.
But I'm wondering if we shouldn't be saying "preventative maintenance" and sometimes just "repair" (for example if there's already an error rate, as in the article's last example.)
Of course, then ya gotta answer the question "to prevent what?" To which the answer is "SNAFUs" or "gremlins" (pardon the WWII terms) such as ones that will make all coding work more expensive later on or will horrify customers by their effects. Or just kill the business outright. I've seen that happen, after having been firmly refused permission to do preventive maintainance on my code. (I'm a worse coder but a better salesman now, so that probably wouldn't happen, now.)
Does this stretch the word repair? No, I think if you're replacing disc brake pads on an old car after X amount of miles, that's repair even if you can still stop the car.
In other words, maybe this has been solved in other ordinary economic contexts, and we should just be brave enough to use them thar words.
This hobbyist mindset is damaging to the software engineering profession in a myriad of other ways.
The fact that some other Z lead to debt T is pointless CYA discussion. One can reasonably ask if a team is well performing if it frequently finds the need to redesign, but that’s a team ability meta discussion not an execution decision.
Execution is just “we’re here; we want to be there with a hope of being this other place in future; how do we get there”
Most business persons I´ve talked to did understood when I told them that the code was a mess, and that if we didn´t work on improving that mess we would start to get into trouble because we will be basing our work on something brittle.
of course thats a silly answer: "to the code base" - "who owns the code base" - "the company" - "well then lets just get rid of that 'code base thingy'"
I guess the word you are looking for is "necessary".
The main difference is that technical debt is hard to quantify. Financial debt is obvious, you see the numbers, interest rates, etc... You see how much repaying your debts will save you money. Technical debt, you know it is there, but you can't easily put a number, you don't know exactly how much it will cost repaying it and how much "interest" it will save you when you address it.
Business person: Oh really! What is it costing us?
Correct response:
Techie: Every new release is taking longer and longer to complete. When we don't give ourselves the time, we have more bugs that are driving away customers.
Time is money, business people understand that. Address that aspect of the issue.
> Companies and business leaders don’t care if jobs are hard or annoying or take longer than they “should”. The difference between a user story taking a day or 3 days is negligible compared to its business value.
And then literally two sentences later:
> They care about time to market.
Poor software increases the length and cost of the supply chain of producing new features, or it makes the supply chain more fragile, or less flexible.
If you know your taking technical debt, explain to them that its like a credit card, but instead of money its time, and we can go ahead and swipe it, but you will eventually have to pay it with interest, and the cost you are paying is every future story is gonna be a little bit slower until things that should be able to get done in a week take a month. ( I have seen this happen personally with a project and the whole thing had to get completely rewritten)
If its unforeseen technical debt, dont call it that. Call it foundational work. Tell them the foundations were not set in a way to support X or Y feature so we need to change/update the foundations to get them the feature they want. This seems to work best. Don't even tell them there is a hack or duct tape solution, bring up the foundational piece first. If business needs has a requirement that it gets out faster, then transition to the credit card analogy and explain they are now swiping the credit card and whenever they complain about velocity use this an example.
The biggest problem is that product managers typically move on or get promoted by the time the technical debt they incurred causes bankruptcy. And fixing that usually tends to involve a rewrite which will have new flavors of technical debt (especially when its in new language), with a new product manager selling their "V2 solution" as so much better. (and successful delivery of that seems to involve them getting promoted or moving to another place soon after)