Hacker News Reader

Comment by tyingq | Hacker News Reader

I have noticed that business folks roll their eyes when "tech debt" comes up. I sympathize, as it didn't used to be that way. COBOL on a mainframe would remain current for decades. Tools and languages are very fragmented these days. I recently tried to get a popular node.js app (tech radar) up and running, but npm just kept bombing out on abandoned packages. The project is 2 years old and already "debt ridden".

Funny, because it's all client side/ browser JavaScript. Node isn't really needed, but that's the toolchain. So it's borked for no good reason.

View on HN

This makes me think part of the problem with tech debt is that it means different things to different people. Some people might describe it as a codebase just not keeping up with this month's latest and greatest JS frameworks, but I think of it as something much more nefarious- low level shittiness and incoherency that tends to seep into long-lived large projects over time. Eventually the lack of refactoring to account for new features or behaviors turns it into a giant blob of spaghetti, where everything knows about everything and what should be minor, localized changes can have unforeseen consequences. This is harder to deal with IMO because it's something that appears so slowly that it's hard to stop in isolated instances ("WTF, you wanna rewrite this whole class instead of just commenting out that one line and adding one more tiny code path to fix this bug right now?!?"). That type of technical debt is more of a boiling frog problem where it's not obvious to everyone how bad it is until serious consequences have started to arise.

Maybe instead of "paying off tech debt" we should sell it as "frog-cooling." I'm only half joking. They'll respond to that by saying "WTF?" and you can be like "Yeah the frog's been in the pot not realizing it's heating up, and is about to boil." Gives it some urgency.

Well said, and often an artifact of "agile" where shortcuts are rewarded.

Great point!

In general I don't think tech debt should be communicated to the business people.

It's an internal part of engineering work, and doesn't impact users. You can think of this as "encapsulation" if you like.

Also what it sounds like to outsiders is "we're taking time off to fix things we didn't bother to do right in the first place". And that's not *100% wrong...

> I don't think tech debt should be communicated to the business people.

This is wrong. Technical debt is almost always incurred because of the business requirements. They need to be made aware the debt is being incurred at that time so they are aware it will need to be paid down ASAP.

Example: a startup is asked by an investor for a particular feature to be implemented for a trade show a week from now. That feature - if done properly - would require a database schema change otherwise the queries will be abysmally slow. Luckily, for the trade show the amount of data being queried is small enough that it won't matter. But as soon as it starts getting used, whoa boy.

Management needs to be made aware that there is technical debt being incurred here. Yes, the deadline will be met and the show will go well. But there better be time on the schedule to do it right afterwards.

>This is wrong. Technical debt is almost always incurred because of the business requirements. They need to be made aware the debt is being incurred at that time so they are aware it will need to be paid down ASAP.

I absolutely loathe doing this - the costs of technical debt are too specific (e.g. 2 hours a week) while the benefits are too diffuse and too hard to measure. If you have a conversation with business people about it it feels like you're having to make a business case for buying pencils.

"We can't afford it do right the first time, but we can sure afford to do it twice when it fails" - Me, a week ago.

> benefits are too diffuse and too hard to measure.

Wouldn't "the feature gets done in 1 day instead of 2 weeks" be a very specific benefit?

It would be, but the most realistic, specifc claim you could typically make is that some hypothetical feature that probably hasn't even been dreamed up yet would get done in less time than it normally would.

It's a hard sell, and that's precisely why it doesn't get done.

Maybe I'm misunderstanding. I think "the benefits [of technical debt]" are the reasons for taking on technical debt. When you take on technical debt it's for a specific feature that's needed, not for something that hasn't been dreamed up yet.

Thanks for a concrete example to discuss.

In this case I'd tell the business that we can absolutely write a hacky version for the trade show, but if they want a fully performant version later, that's a separate story, and much of the work going in to the first story will have been wasted.

Maybe we don't even disagree on much there.

The scenario I had in mind was when you decide to rework/refactor some existing code because it's badly designed because of incompetent original design, changing requirements or whatever else.

To me that's just an ordinary Tuesday, all part of the work we do all the time, and nothing I need to communicate, any more than I need for when we take a lunch break.

Maybe this is the difference between thinking of the business as my "customer" rather than my "boss".

I'm not sure about that, most deadlines are arbitrary. There are exceptions but I wouldn't class a trade show as that. It doesn't come from business requirements, it comes from poor management.

And somehow other priorities preempt “doing it right” and the debt stays unpaid for much longer than is healthy...

They are paying for it, so I'm not clear on how you hide it. They'll figure it out, and you look disingenuous when they do.

I understand GP as saying that if business people know about technical debt, it means you're giving them too much details. Business people care about features being implemented and bugs being fixed; they don't (shouldn't) care if implementing a feature is 1/3 direct work on the feature, and 2/3 fixing the architecture to make the direct work on this and future features faster - but if you communicate this split to them, they'll start asking if you couldn't cut that 2/3 part out.

I mostly agree with this in theory, but there’s a tragedy of the commons problem when working on a development team. A developer who takes the quick-and-dirty route will appear more productive in the short term than one who tries to maintain long-term development velocity.

If they’re working on a shared codebase together, the latter developer will end up cleaning up the mess left by the former and getting less recognition from management. In all likelihood, this developer will either leave due to resentment, be laid off for underperformance, or stop doing the maintenance work. In any case, there’s no longer anyone seeing to the long-term development velocity and the team’s productivity will slowly grind to a halt.

I can think of a few ways of combatting this though.

1) Slack in the system, meaning there is time without explicitly defined tasks that have to be done.

Basecamp does something like this where they take 1-2 weeks off scheduled work after a 6-week cycle to let their employees fix things up [0].

2) A good definition-of-done plus a technical culture focused on quality.

My current workplace has a culture of valuing correctness and quality over velocity, it has been a nice change of pace from my previous workplace where velocity was valued over everything else, leading to lower velocity as our code became worse over time.

0: https://3.basecamp-help.com/article/35-the-six-week-cycle

Yeah, I've been on a team like that, and I can only recommend either (1) leaving for a functioning team, or (2) fix your team. And I don't know how to do (2).

I'm talking about how the development team as a whole should relate to other parts of the business.

Thanks for explaining my point better than I would have :)

But business people know all about debt because it's common for a business to operate on debt. They can relate. And, as the advice usually goes, it's better to first address your debt before going into saving and investing.

The interesting kind of technical debt is when you realize you modeled the problem wrong, or the problem has changed and you need to change the model. A simple example is an auth system that assumes a one-to-one correspondence between account and user login. Then you get, for examples, agencies that are conceptually one account but have multiple logins (so each client can only see their own account). Oops, that breaks the model. Changing this requires database migration, code changes, UX changes, and so on. It's a conceptually simple change but has wide implications.

Business folks are more sympathetic to that kind of tech debt. The eye rolling is more around silly plumbing, version upgrades, etc, that add no business value. The React ecosystem is a good example to me. No two shops use the same stack. And alternatives like Angular are more "batteries included" and stable / "good enough to get the job done". But less popular.

I wouldn’t categorize this as technical debt unless you’ve deriberatly choosen to implement the wrong abstraction first, to get the product out the door earlier, or some other short term benefit. Technical debt is a deliberate action with some upfront knowledge of its consequences.

“It didn’t used to be this way” because of the internet. Not because the way COBOL programs were developed were inherently superior.

Once these cobol powered servers were accessible to hacking, “not changing anything” no longer worked.

https://www.computerworld.com/article/3181809/cobol-plays-ma...

I get your point, but it feels like things have swung too far in the opposite direction. Compared to other engineering (chemical, civil, industrial, etc), we do a lot of change for little good reason. There's too many ways to solve the same problem, which kills "best practice".

I’ve recently been reading ‘A deepness in the sky’ and it has the concept of ‘Programmer-Archeologists’ exactly for this reason.

It’s set many thousands of years in the future and I have trouble imagining how many old versions of packages and libraries would exist at that point.

Trust me, in 20-30 years, after the apocalypse, someone needs to turn on a water filter and npm can't download the correct package... and they die of dehydration... just write the Black Mirror episode around it!

> COBOL on a mainframe would remain current for decades

Only if the underlying problem solved by the program doesn't change for decades, and even if this case, the piece of software in question is a constrain to the industry using it. I'm sure a dentist would loves to have some fancy REST 4.0 BUZZ-WORD-OF-THE-DAY client management system.

I am using some industry "standard" industrial CNC software and it not only constrains me to 15 years old hardware but also restrict me to use programming quirk specific to this software which very much qualify as being "tech debt". In this case, the business is built around the software.

There's really a few distinct concepts here, and I think it's important to be precise.

- Keeping up with platform churn. How much of this you will do is really a CTO level choice, in terms of a) permitting internal platform teams to break backwards compatibility, and b) permitting adoption of trendy technology from outside.

- Knowingly trading off quality for speed to meet a deadline. This is tech debt in the strictest sense and you can quantify it as you accumulate it. Tech debt comes from a business / product management choice to force a project to release before it meets standards.

- Seeing better abstractions and decompositions, new test cases, observability hooks, etc. with the benefit of hindsight and experience. Examples: we found four bugs in this module this quarter and it's really complex, I see a simpler and less error-prone way to rewrite it. There's a lot of interest in adding new features with a certain shape and each time you have to touch code in three different places, let me consolidate those so you only have to touch one. People keep asking a particular question that requires painstaking correlation of different logs, let's add a new logging topic that answers it directly. Stuff like this. These are never strictly necessary and business impact is hard to quantify, but if you do this stuff never, you're going to have a lot of cruft in a few years.

I've got Javascript projects of a couple of years old. There are certainly things I'd do differently now if I were to set them up today, but I wouldn't consider that technical debt: those things are not giving me practical problems in the foreseeable future.

The only of such projects that I'm still running which does have significant technical debt, from my point of view, is the one I set up without a CI system and without a package manager with a lock file (those didn't exist back then) - I cannot update that code today, because I cannot build it. Rewriting that one with a reproducible build set up is something I consider tech debt and which is still on my TODO list of intending to solve one day.

Back then technology could set more boundaries than today. Most of these old mainframe systems I have worked with, use batch jobs (running at night when the system is offline) today being offline is often not acceptable and the users can't wait until the next job to have their data in the system.

But I agree that being conservative with pulling in new technologies and dependencies, new and good is not the same.

I think the biggest thing with tech dept is communication. We can do this in 1 sprint but then it will cost more in the future. If business always choose the quick matter how you put it and explain when it causes problems, yeah... :(

Java is pretty good at this. Before jigsaw we had projects that we hadn't touched for 13 years and they still compiled on the newest versions.

There's positives and negatives to this of course.

Reply on news.ycombinator.com