Hacker News Reader

The problem is that there is never an objective right way. There are infinite wrong ways, and usually a handful of ways that are just fine with different pros and cons that are not always clear up front.

A lot of the time when people say technical debt they mean a developer not taking the time to understand some code they inherited (or they wrote and forgot about), and wanting to throw the baby out with the bathwater.

If think you ask ten developers the best way to refactor a complex program you'll get 100 answers.

But I do agree that deliberate technical debt is more common on a decent team. I definitely have left many comments like "I know it would be better if I did XYZ, or ABC, but the boss wants it now, and I'm tired, so it's going to be a monstrosity"

the 10 -> 100 bit is absolutely right. a cross functional team has to learn how to work together well, and spend a non trivial amount of time discussing the problem and tempering solutions until something is achieved where each of them are some state of “happy”. This is I think the crux of many tech debt issues in companies

The other possibility (which is common in startups) is that often the “right way” is different depending on the scale of the system you need to design for. In cases like this you end up with technical debt a year down the line, but at the time the feature was shipped the engineering decisions made were extremely reasonable.

I’ve seen a few colleagues jump to writing off all technical debt as being inherently bad, but in cases like this it’s a sign of success and something that’s largely impossible to avoid (the EV of building for 10-100x current scale is generally negative, factoring in the risk of the business going bust). There’s a kind of entropy at play here.

Big fan of tidying things up incrementally as you go [1], because it enables teams to at least mitigate this natural degradation over time

[1] https://sophiabits.com/blog/be-a-tidy-kiwi

> The only way it could be passive like the article describes is if the developers don't know or otherwise don't consider the "right way" and go straight for the "fast way". I hope to never work on a team that operates like that.

I've been on teams like that and it's absentee management. There's two reasons: the management is technically inept or the execs and other stakeholders are taking up too much of their time. Sometimes it's both.

This creates a situation where either the most technically competent team member takes over responsibilities or the team just loses coherence.

Beyond that there's also often a severe lack of involvement from the broader organization where everything is siloed.

The quality of the dev team reflects the quality of the business. Implementation details are not so different from "operations" in other fields. Makes no sense we have such a terrible state of things in software at some places other than a lack of talent and residual people who should have retired or pivoted careers a long time ago.

There is often a third alternative: do not shoehorn it into something, nor rebuild what you have to fit this new thing, instead build the new thing on the side.

I sometimes have worked with engineers who believe they know what “the right way” is, or spend a lot of time trying to figure it out. And I have certainly worked on legacy systems persons like that have built. It’s not all fun and games.

The less we entangle things the easier it is to remove cruft when it is no longer needed.

You’re completely right about entanglement: Id go further to say that simplicity in its purest form is almost always more useful than clever upfront design, but it’s funny because clever upfront design process can be tweaked to bias simplicity.

What I’m trying to say is that there are two ways of designing systems: Make them flexible to meet unknown future objectives by incurring tech debt, or build them so simple that they are easy to change when those unknowns come in.

You may say that there’s no “right way” to build systems, but some ways are certainly better, perhaps it’s possible to distil a way from that, but i agree that it can be paralysis inducing. can’t go wrong with building Simple working systems, imo.

How would you recommend implementing a feature that might get rolled back or fundamentally changed depending on user reaction to it?

Doing it the "right" way incur a lot of up-front expense that will be wasted if the feature is rolled back.

This is a perfect example of when deliberately taking on technical debt is the smart thing to do. You build the feature the "fast way", deliberately incurring technical debt to get faster feedback on the feature. If the feature doesn't work out, you can remove it quickly. If it does work out, then you can be confident that building it the "right way" is now worth the investment.

Technical debt is just like regular financial debt in that it can be a powerful tool when leveraged correctly.

This. 100% agree