Hacker News Reader

Amen.

And debt is a really un-useful term for this, too, IMHO. More often than not, when you're down the line and dealing with the concequences of prior shortcuts the optimal solution you can think of now is different to the one you considered at the time of the original decision. And it also completely ignores the concept of great, perhaps also expensive, decisions taken in the past that are now no longer such a good fit. They weren't knowingly done as a debt, but the world changed.

The word "debt" has too much associated meaning. People understand the term too well. Instead I'd like people to just talk about "change" instead. Value judgements about the reasons we got here don't add anything useful to the decision on the tradeoff as to whether the suggested change is worth doing.

I’ve always explained “technical debt” to program managers in the finance industry as behaving more like an unhedged call contract than debt.

Ha, I love that. Either you reap a benefit or it blows up in your face!

Or you reap benefit until it blows up in your face at an unknown time :-)

What engineers mean by debt toughly falls into two buckets. The first is actual debt, coding done on borrowed time, either consciously or unconsciously. The second is when a lack of experience, knowledge, laziness or other bad habits cause the code written to not be adaptable/agile enough to later have a low cost of change when the world changes.

Many reasons and excuses for each, but the first one is usually due to business reasons (why polish and mature one feature when you can develop five) while the second is due to engineering reasons.

See the comment I was replying to. Mostly it means "I want to do x and I can't think of a better justification".

> A codebase that is brittle - meaning things break easily, testing is low, or where maintenance or new dev is difficult - is a genuine business problem. The solution to that is engineering managers that can make a persuasive case

I still think we need better ways of properly measuring this "brittleness". And also long term velocity and feature flexibility and other factors that are sacrificed when accumulating tech debt. Often these things are so vague that it really just comes down to a 1-vs-1 between the manager (who wants the feature out now) and the engineer (who may have been drinking too much microservices kool-aid). "I could have built this faster if we had switched to React last year" ok but roughly how much faster? Better measurements can make these discussions more objective, just like how scientific studies and data analysis are used in real politics.

Of course we can't ignore the glaring issue with this paper specifically and it's relationship with Codescene, but I do wish to see more studies in this direction.

> And also long term velocity and feature flexibility and other factors that are sacrificed when accumulating tech debt

Indeed. Perhaps spending 42% of time overcoming tech debt is steady-state, and paying the debt down shrinks the pie (i.e. customer base).

It is an act of balance.

"I could have built this faster if we had switched to React last year" ok but roughly how much faster?

We can't even accurately estimate (ahead of time) how long it would take in the existing stack, much less in a different one.

> We can't even accurately estimate (ahead of time) how long it would take in the existing stack, much less in a different one.

We already try to measure these things with Agile and sprints. It's not perfect but many would argue it's better than zero estimation at all. However often the focus on sprints leaves long term investments like code quality out of consideration. More studies and data can provide better information on when these trade offs are worth it.

Imagine if a large scale study came out that said companys that migrated to microservices ended up spending on average 2 additional months on migration if they delayed the migration by a year. Certainly this would be useful information for other companies thinking about the same.

> meaning things break easily, testing is low, or where maintenance or new dev is difficult - is a genuine business problem. The solution to that is engineering managers that can make a persuasive case to non-technical people for why something needs to be done a different way

At an engineering company management up to the board should all be engineers.

Then, these conversations become much easier, since things that break (and a pattern of repeated failures for the same thing) should be obvious to any real engineer.

> But as a founder and an active software engineer, far too often "technical debt" is used by programmers to advanced their personal preferences, which may not be aligned with the businesses in any way.

That's often a comp problem. Are your engineer's incentives aligned with the company (via stock options for instance)? If not, it's probably better for them to refactor your product to use whatever tech is pushed by the place they want to jump ship to (for a better comp package of course).

> using a mono repo (again, zero business problems caused)

Mono repos have a lot of advantages (most notably that it makes cross-component changes atomic). There's a reason Google adopted that model.

> using any number of 3rd party libraries (vs the developers desire to build from scratch)

Keep in mind there's a hidden cost to any third party dependency, especially if you have to modify it but your patches won't make it upstream.

> At an engineering company management up to the board should all be engineers.

> Then, these conversations become much easier, since things that break (and a pattern of repeated failures for the same thing) should be obvious to any real engineer.

This is a fallacy that I often observe in engineers. We believe that our work is the one that brings value and all decisions should be made by people that do what we do. We also believe, that non-tech folks cannot understand what we try to explain. I also very often observe that many engineers have no idea of basic concepts that are required to run a business (and often, no interest to learn about them). Opportunity costs for example: We could pay down this tech debt, but what else could we do with the same money. We all love shining codebases over everything else, because it makes our work easier. But finance folks have other priorities - and balancing those priorities is one of the core tasks that management has. Placing only tech folks in management is unlikely to produce balanced results.

> This is a fallacy that I often observe in engineers. We believe that our work is the one that brings value and all decisions should be made by people that do what we do.

And yet it does. At least, at tech companies.

> We also believe, that non-tech folks cannot understand what we try to explain. I also very often observe that many engineers have no idea of basic concepts that are required to run a business (and often, no interest to learn about them).

That's a very good point. However, my observation over the years is that great engineers can pick up business concepts (it's often a requirement to graduate anyways) but non-technical managers can't generally master engineering to the same degree.

I share your perspective. Ultimately, I see the situation as somewhat analogous to having a professional work on your house. You rely on their expertise to direct what is and isn't essential, and really lack any ability to measure the outcome (e.g. is this harder wearing material or building technique really worth the extra time and money).

Again, as you say, I think the solution is simply to develop trust with the stakeholders to whom you're trying to sell the ideas. Technical leads - in a unique position of understanding the costs and the benefits - must be vigilant to bat away the spurious claims that certain topics (such as those you mention) require addressing, as trust lost is difficult to recoup.

< using any number of 3rd party libraries (vs the developers desire to build from scratch)

HN is strewn with stories of people with dependencies on log4j, left-pad, and who knows what else. A programmer wanting to move off log4j and build logging from scratch might seem like a personal preference for some time, until the entire tech staff suddenly has to go into lockdown to remove dependencies on a dependency like log4j.

It can vary one way or the other, but if I advocate for not using a 3rd party library there is usually a good reason.

I would need a very strong reason to believe an internal team could build a more reliable and secure library than Log4J, and commit to support and maintain it for as long as we need it, before I would think writing an internal log library was a good idea.

Outside of very large software companies, developers add business value by writing things that don't already exist. Spending time rewriting third-party libraries has dubious business value.

Writing a reliable, secure function that writes messages to stdout might be all that a project needs.

The risk of third party libraries is that they often do far more than needed for an individual project. Log4j got into trouble with a feature that supported remote lookups over LDAP.

> Writing a reliable, secure function that writes messages to stdout might be all that a project needs.

That's how it starts. Then you need to log to file. Then you need to rotate those files. Then someone asks for a custom format. Eventually you end up with a crappy internal Log4J clone.

> using promises instead of observables (in a non RX codebase)

Feels like the opposite?