Comment by hardwaregeek | Hacker News Reader

Comment by hardwaregeek | Hacker News Reader

Parent Full thread

I've become skeptical of people talking about technical debt and clean code and all the standard Fowler/Uncle Bob/PragProg-isms. Not because they're wrong. If anything they're all right, but in a rather vacuous, well-yeah way. Yes technical debt is bad. Yes we should start with a design. Yes we should do refactoring. But using the analogy of the author, that's like telling someone who's overweight and eating a lot of junk food that they should "eat healthier and exercise". Well yeah. They probably knew that already.

And so many people try to make it a dichotomy. Like that diagram of a project with a design versus without. That's not a fair comparison. What does a design even mean? Wireframes? A written document of features? How do we change this design? What's the way in which we get feedback? And what sort of projects are we talking here? A programming language is very different from a website. And what even counts as no design?

Some other notes:

  - I'm not sure the author correctly used the Pareto principle. It's not just a generic "split things into 80/20" but a specific observation on how 20% of the causes result in 80% of the effects.

  - The post could have used a quick proofread. There's quite a few spelling mistakes and poorly phrased sentences. I totally get if the author is not a native speaker, but they could easily enlist one to help (if the author wishes, I'd be happy to proofread—contact me).

  - I get the whole "make this post fun with cats!" but honestly I'd prefer a straightforward example with no funny images. Maybe that's just my grumpiness.

> Yes technical debt is bad.

Technical debt is like any debt. It's bad if you come due on it and don't have the resources to pay it off. Unlike cash debts, technical debt rarely comes due in a tangible fashion.

If getting to my next round vs. failing means leveraging technical debt, I'm going to do that by all means. It's not necessarily easier to fix tech debt at scale, but having more resources means it's less impactful on bandwidth.

Financial debt is okay if it gives you an important advantage now, and you can pay it off later, and you remember to actually do it.

If you get into debt so that you can have a nice new TV quickly, and you forget to pay it off, so it keeps increasing, and you only pay attention to it when the debt collectors start calling you... that is a problem.

In my experience, most software debt resembles the latter case. The goal is to meet a deadline sooner, and there is absolutely no intention of spending resources to fix it later, unless the customers start making too many tickets.

When a manager says "later" or "low priority", it usually means "never, unless we absolutely have to". Technical debt is always a "low priority" that will be addressed "later".

Yes, there are situations when meeting a specific deadline is critical, and it is a rational decision to cut some corners and fix things later. The problem is that after the deadline is met, the "fix things later" part is usually forgotten. A new deadline is set, and new corners need to be cut, etc.

This is my preferred way of thinking about it too. I wouldn't say debt in general is universally bad, and so I wouldn't say the same thing about technical debt either.

Technical debt can save a company by pushing something forward and launching a product sooner than a competitor. It can save a big customer by fixing a bug for them quickly that if not fixed immediately would have caused them to cancel a multimillion dollar contract. It can also eat away at a company if you let it accrue for decades and never pay it down.

The latter being much more likely to happen to the average company than the former, in my experience.

I'm skeptical of any Uncle Bob-isms (and to some degree of Fowler's stuff) as well, but if you want a good description of technical debt and why it's actually a problem, Ousterhout does it nicely in his "A Philosophy of Software Design".

That book is a little gem, short and well-written

Yeah. The probably rarely is the debt itself, but the processes and circumstances that lead to the debt being accumulated in the first place.

Looking back and going "this is bad!" at your 'technical debt' isnt all that interesting. It's much more useful to understand what lead you (the team) to take those shortcuts in the first place.

Reply on news.ycombinator.com