Hacker News Reader

The article ignores that there are many ways to initially write code, and some are better than others. “Creating technical debt” is about not spending the time to find a good way to initially write the code, leaving it to a later point in time.

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.

> is about not spending the time to find a good way to initially write the code

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

There can be many very valid reasons for creating technical dept when writing code.

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.

Sure, and that's actually 100% normal in business -- it's called the "J-curve". Lots of businesses big and small start their lives, or even start some new project or expansion within an existing business, by borrowing money and then paying it back. The key thing is 1) borrowing money "strategically", and not just willy-nilly and 2) paying it back when you can afford to, rather than continually paying interest on it.

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.

> “Creating technical debt” is about not spending the time to find a good way to initially write the code, leaving it to a later point in time.

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.

You made a good argument that generalizing is an investment that often doesn't pay off.

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 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.

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.

I think you’re being downvoted because your comment seems, especially in the first two paragraphs, to imply that:

- 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).

> - competent programmers who do a good job write the best code in the shortest amount of

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.

all things being equal, shipping a feature with a 2 weeks delay is certainly bad, but often all things are not equal: the slower dev does something more and the does something less (I'm ignoring the case where the slower dev just slacks off).

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.

Debt may not be an overwhelming problem in itself until misfortune creates issues which would not be overwhelming otherwise, usually in financial terms.

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.

> ...but when you have a lot of debt, lenders are cautious about lending you money

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.

This is what technical debt means to me. Decisions/shortcuts made early in the project that lead to lots of lost time when adding something new later (the lost time is the interest payment).

Good examples of this are premature microservices, no good separation between modules, bad database schema design, etc...

I would add that technical debt by itself is not a bad thing. Just as real life debt is not a bad thing. It fact, it can be essential if you want to do anything at all.

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.

Technical debt by itself is a bad thing. It's just that, much as with actual debt, it's often worthwhile to accept a little bit of bad if you get a lot of good in exchange.

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).

>I was going to write that there's no reason you'd want financial debt qua financial debt

Under what circumstances?

What about https://en.wikipedia.org/wiki/Time_preference ?

You may want to take on debt, but it's the money you get in the short term that you want (or the stuff you spend it on, really). The debt itself, you'd prefer not to have, if everything else could be equal.

> was going to write that there's no reason you'd want financial debt qua financial debt.

Yes you actually do want debt because it is tax shield.

https://en.m.wikipedia.org/wiki/Tax_shield

That certainly makes it more attractive to make deals that involve taking on debt. But note that it's a deduction, so the amount you pay to service the debt will always be more than the taxes you save. If you could simply not have the debt anymore, you would be better off. You still don't want the debt itself.

Exactly this. I thought the article was struggling with the concept of metaphor.

He redefines what technical debt means and then claims the new definition doesn't happen, so what other people define as technical debt must not happen either.

This depends on the situtation. Especially when writing something that doesn't have a good existing pattern (think research code). After writing something it might become clear that a everything would be better off one way or another, and adding new research features might be impossible given the current structure. This is why most packages for doing machine learning research have just turned into autograd tools. Picking any fixed structure for research code is effectively blocking off some avenue of research.

I need some software to solve a business problem I have now, in 5 years time my problem might not even exist, there may be a better solution on the market, my company might not even exist - perhaps because my outgoings were all on expensive developers refactoring into the latest and greatest framework.

Software is not the end goal for most businesses, it's a tool to get

I’m not sure if this is #1 a geographical-cultural thing, #2 a generational thing or #3 a natural evolution thing but I’ve been in the game from mid 1999 onwards including the Dot-com bubble (yeah get off my lawn, ok boomer etc etc).

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)

One reason for such change I can think off is application of Goodharts law to estimates, when some managers base the programmers potential pay raise on how much faster than estimates the programmer was.

Well said.

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.

It's not debt because unlike (financial) debt, there is no way to not take it or to repay it.

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.

I'm writing this as a middle-class person, who has to go into debt if she wants to buy a house. It's not a bad thing - I want the house now but saving up would take too long. It's just a choice.

"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.

Branding every possible decision as "technical debt" is intellectually dishonest. Each decision you make has consequences. Technical debt is the result of choosing an expedient path over one that supports your wider goals. It's true that there's no perfect state, but only because this is engineering, where we don't care about "perfection", only tolerances.

It seems to me that rewriting stuff is what you do when you can't stand to maintain it, i.e. pay the interest, hence it's like declaring bankruptcy.

> You “repay” the technical debt by fixing stuff that causes problems

Well, that sounds a lot like maintenance.

Maintenance is the repayment, not the debt itself.

As the GP said:

> 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).

Maintenance of good code is very different than going in and fixing a bunch of TODOs so the thing won't break outside the happy path.