> This is because the real cost of software is time.
Exactly... And so it follows that technical debt is the debt of time. What your quick and dirty ^solution^ achieves today will be more expensive in terms of time, to fix/scale/debug/maintain tomorrow.
How is the author not seeing this? There is a cost and a value to everything. A highly valuable quick and dirty solution today makes sense only if it will cost less to throw away, replace or clean up.
Sigh, I'm tried of this industry that keeps not just reinventing wheel but rediscovering the entire process that leads up to it.
And equally importantly management and engineers disagree on “when” to service the debt.
More often than not a product feature gets prioritized over repayment. And management is perfectly happy to have on calls suffer late nights fixing random bugs that proliferate.
Worse is, as time goes on, the knowledge of why a tech debt was introduced vanishes. So everyone gets scared to touch that code with a 100 ft pole.
It’s like building on shaky foundation. Once enough floors are built it becomes impossible to fix the foundation without tearing down the building.
It's rushing things out the door without due diligence. Software these days is shipped at breakneck speed because of market competition, i.e you're not a proper shop if you don't 'release early, release often'.
This is why software should be more craftmanship rather than a frantic race, and done with love and care. It absolutely should not be rushed out the door.
> If the technical debt is a problem, 1) we shouldn’t have put it in there, and 2) we should include it in our estimates and address it.
Yes. Don't tell your boss that you'll need to take time to address technical debt. The boss will always say "No don't do that, just add the feature". Sometimes they add "We'll fix that later."
Later never happens and eliminating related technical debt is part of implementing the feature.
Don't ask your boss about this stuff. It's part of your job and it's something you understand that your boss probably doesn't.
>>“This code should last 20 years” should, for most people, be fairly low on the list of desires for a technology stack.
>> But let’s not kid ourselves that the stuff we’re writing is even intended to last a long time.
Well, it depends. If you write custom software for enterprises, they very much see it as a long term investment. Software grows with the company and is embedded in it. Nobody wants to pay for complete rewrites every five years..
> this approach can be the most cost efficient one.
No it can’t. Quick and dirty? Sure. Take on some tech debt to get to market quicker. Blindly copying and pasting? You’re never going to build functional software that way. This guy was committing code with syntax errors that he’d obviously never even run. How are you going to get to market quickly that way?
> Have you ever started a project that should take a couple hours with a fifty dollar budget, and realized at the end you spent a whole month on it and spent close to a thousand bucks?
Ah man, costs aside, that's my last weekend and probably the next few ones as I've been trying to make my old Motorola Xoom tablet run a modern kernel. When/if that's completed, the return on investment will be a net loss.
> if slow compilation is such a pain point, I wonder why it takes seven years and counting to fix this bad decision
I'm not sure it was a "bad decision" if it was something that can be addressed after the fact and allowed them to ship working software more quickly.
The vast majority of the popular projects I am aware of have this kind of technical debt, likely due to survivorship bias. Project teams that refuse to take on technical debt are rarely successful enough to become popular.
> Is it better to put that work in up front for the 0.01% chance you'll need it? I think not.
Over a sufficiently long time horizon, the chance is much greater than 0.01% and the longer you go without doing the work, the more it costs to do the work.
Sure, it's more a problem that bites you when you've become a big enterprise, but it bites hard, and some of us work in big enterprises on systems that could reasonably be operational for generations going forward (and perhaps have been going backwards.)
Sage wisdom, I wish managers took this up a little. They'd improve throughput by 10x or so in a week, and new developers would have shorter lead times. Plus quality would go up, the fastest most correct code is the stuff you never write.
> you have to be prepared for a higher than average error rate from your people.
Exactly this. From first hand experience, when forced to deliver under time pressure, I cut corners.
This means, I might be able to deliver the feature. But the tradeoff is it adds technical debt and physical stress, which needs to be dealt with afterwards.
Furthermore, if you have a family, it also takes a toll on family life.
> But they should consider whether this matches the size/scope of the problem being solved
In professional software development projects, specially legacy projects, often times the complexity is not justified by the problem. There is always technical debt piling up, and eventually it starts getting in the way.
> Software seems to be overrun by a mentality that any future cost is worth it to save even 1 minute of development time today.
...
>it seems that people get promoted away from their problems so they're not the ones to solve
This has been going on forever and it's anything but software specific.
> Demanding perfect time-boxing ahead of time is a recipe for disaster.
Dear client, this task will take 2 to 6 hours. If I find out it will take longer than this, I will reach out.
Dear client, I am 1.5 hours into this task. Based on my experience, it look like it will take 7 to 10 hours instead. Should I continue?
For all of this to work well, you need to have experience in estimating well and also understand that whatever number pops into your head, multiply it by 2 and tell the client that. I have never had a client be pissed at me because I finished something for less time/money than they were expecting.
That said, this sort of thing should really be used for highly indeterminate tasks, like fixing bugs.
> CPU time is always cheaper than an engineer’s time.
But my time is sometimes cheaper than 10 other developer's time. Or 50. Or all of our customers now and in the future: https://xkcd.com/1205/
Additionally, a fatal flaw of most project management theory is that it measures time as the constrained resource, which is rarely if ever the case. The real constraint is not time. It's either attention or energy, depending on the context (and motivation). We are not machines. Taking 10 minutes off of a process doesn't necessarily allow us to get 10 more minutes of work done, while taking 5 minutes off of another may actually save us 15.
> it makes sense to start cleaning up the codebase.
This is very optimistic assumption that people will actually clean the codebase at some point. From what I've seen technical debt can stay very long time. Temporary hacks can become permanent.
Spikes/prototyping can be quite effective, but to be effective in writing spikes/prototypes a team must be disciplined to rewrite/refactor later. And from my experience teams are often not very disciplined and pile of spaghetti code begin to grow...
> The problem with this approach is that if the tech debt
> catches up with you faster than you can figure out the
> product-market fit. In this case it gets harder and harder
> to move and instead of going faster you go slower
Yeah. This is what I've seen. Even in startups quick and dirty code can be developed over months. And in such long time pile of spaghetti just piles up (people can make quite a mess in days. Imagine what they can do over months...).
> If that were a problem in reality, the markets would be punishing companies where that happens.
Oh they do, I can show you plenty of examples. But it is never the problem of the people that created the issue in the first place.
Think of these things as time-bombs of technical debt. They'll blow up sooner or later, usually later, and that makes it that much harder to deal with the fall-out.
Also: for all the lessons about economy made here: I would happily argue that doing things right is actually cheaper in the long run and possibly also cheaper in the short term, by applying the techniques described in proper measure you can save yourself a ton of headache.
But of course that would first require a basic understanding of what the article is trying to put across, which if your time horizon is short and your deadlines are looming likely isn't going to be on your agenda.
> It's a tiny fraction of total programmers building databases and stuff like that.
Software you build tends to live longer than you think and tends to be incorporated into places that you can not foresee when you make it.
The 'tiny fraction of total programmers building databases' should include the huge fraction of programmers building embedded systems, APIs, operating systems, libraries and so on. All of those will have life-spans in the decades if they're done halfway right.
Not really
I have a program which is a right pain, and takes an hour to do a yearly task. To clean it up would take about 200 hours.
The program is unlikely to be around in 20 years time, let alone 200.
reply