The Way We Look at Technical Debt Is Wrong

I see a lot of wisdom in this article and I find myself nodding, but I'm dubious whether it's effectively communicated from the article per se or its just my experience dovetailing with the author's. The problem is that "technical debt" is an analogy, and like all analogies, it breaks down. It's never a choice between writing perfect code or hacking together the fastest ugliest thing that could possibly work, rather all long-term software development is a continuous series of tradeoffs heavily dependent on an unknowable future.

Consider the center-point of this article:

> I view technical debt as any code that decreases agility as the project matures.

Well, any given piece of code can have positive or negative value based on what change you need to make in the future. You can have a perfectly factored, elegant piece of code which becomes useless if the job to be done changes, at which point you are better with no code than the previously ideal code. On the other hand, you can have a module which is ugly as sin, unreadable, and horrible in every way, but it does a job that never needs changing, and it's isolated enough that no one ever even has to look at it or consider it.

So the very judgement of the scope and severity of technical debt depends non-trivially on the future. Individually design decisions can be critiqued, and the likelihood of certain types of changes can be weighed out, and certainly the best engineering and product teams are very very good at this, but the fact is that the whole endeavor is terribly fraught and difficult to concretize.

All that said, I think the author is absolutely right that engineers often have a proclivity to polish some bit of code or architecture when their time would be better spent elsewhere, but it's just a tiny microcosm of the problem facing all startups: you need to build a money-making machine, and you have infinitely many dials to turn, with only a handful of (hopefully) smart people on a very limited runway. How do you make decisions day-to-day about where your greatest marginal utility lies? I don't think there are any rules of thumb that are globally applicable. If you are lost, a blog article is not going to help you. The only hope is to gather feedback as widely and quickly as possible and be brutally honest with yourself.

>If a company (like Microsoft with Excel) is slow but eventually gets there, then they are successful.

Excel was successful because Lotus decided 123 had so much technical debt it would be a good idea to "upgrade" the old assembler code to C. This took at least a year longer than planned, and introduced a lot of bugs and incompatibilities.

Meanwhile Windows had arrived, and the planned Windows rewrite of 123 never happened as scheduled.

So it wasn't so much that technical debt killed 123. But poor management of technical debt certainly did.

Effectively the C rewrite was a complete waste of time, and Lotus should have aimed for a Windows release as soon as they could.

It's nice to be able to say this with hindsight, but it was doubtless much less obvious at the time, when Windows was barely considered a mediocre visual DOS shell, and certainly not a serious OS.

Bottom line - you have to be smart, prescient, and a little lucky to manage technical debt. It's not just about getting the code right - it's making decisions with educated guesses about where you may be a year or two from now.

And that's hard.

Eh, referential transparency is a thing. And that idea can be extended beyond a simple function.

It's totally possible to contain horrible sins behind a clean API. I've done horrible things, but those things don't leak all over the whole project.

On the other hand, i worked at the same place for a long time. I got to see the benefits and consequences of my mistakes and successes over years. I do think i burned out. It took me a long time to learn how to contain nuclear waste.

In the end, it's easier to just work someplace that doesn't put crazy demands on developers. There's a continuum of perfection functionality. unfortunately for new developers, it takes a while to figure out where you lie on that line. Finding a place that's close to your preference is really best.

It's kind of like driving. Everyone slower is a Sunday driver, everyone faster is a lunatic with a death wish. I'm happy with homogeneous drivers - too far from the mark and i get nervous. I'd bet it's the same for pretty much everyone else as well.

I like the application segmentation strategy (when you can get away with it); it reminds me of the unix philosophy but over a message bus instead of pipes.

Running things over a message bus is slightly more work than one large application, but the upshot is that it lets you experiment with new technologies and ways of doing things without betting the entire product/company on it.

So... be agile agile agile... but, not really.

Don't waste time trying out the latest-and-greatest cutting-edge development techniques. Except SPAs (Single Page Applications) because those (somehow) take less time to implement and are 'easier' to iterate than a traditional UI.

Don't waste time perfecting the data models. Unless you're talking about data structures (ie they're totally not a type of data model) because your data structures should be perfect from the start so as to avoid the technical debt of modifying them later.

Don't waste time enforcing the SRP (Single Responsibility Principle). Unless you're talking about 'siloing areas of concern into microservices' because splitting responsibilities (and designing custom APIs to drive them) isn't just another approach to enforcing SRPs. Designing APIs that connect your app to it's dependencies in a manner that won't change (and break things) later is easy right?

So, code, code, code fast. Don't waste time early on developing a sane architecture, except when you want to spent time developing a sane architecture early on to iterate quickly later.

Forgive the sarcasm, this isn't a troll. I'm just pointing out the blatant contradictions.

The only valuable advice I can grok from this article is. Disregard TDD, build a MVP, push it into alpha/beta ASAP, fix bugs later.