←back to thread

466 points 0x63_Problems | 1 comments | | HN request time: 0.209s | source
Show context
dkdbejwi383 ◴[] No.42138113[source]
> However, in ‘high-debt’ environments with subtle control flow, long-range dependencies, and unexpected patterns, they struggle to generate a useful response

I'd argue that a lot of this is not "tech debt" but just signs of maturity in a codebase. Real world business requirements don't often map cleanly onto any given pattern. Over time codebases develop these "scars", little patches of weirdness. It's often tempting for the younger, less experienced engineer to declare this as tech debt or cruft or whatever, and that a full re-write is needed. Only to re-learn the lessons those scars taught in the first place.

replies(8): >>42138467 #>>42138490 #>>42138644 #>>42138759 #>>42139133 #>>42141484 #>>42142736 #>>42143702 #
bunderbunder ◴[] No.42138490[source]
I recently watched a team speedrun this phenomenon in rather dramatic fashion. They released a ground-up rewrite of an existing service to much fanfare, talking about how much simpler it was than the old version. Only to spend the next year systematically restoring most of those pieces of complexity as whoever was on pager duty that week got to experience a high-pressure object lesson in why some design quirk of the original existed in the first place.

Fast forward to now and we're basically back to where we started. Only now they're working on code that was written in a different language, which I suppose is (to misappropriate a Royce quote) "worth something, but not much."

That said, this is also a great example of why I get so irritated with colleagues who believe it's possible for code to be "self-documenting" on anything larger than a micro-scale. That's what the original code tried to do, and it meant that its current maintainers were left without any frickin' clue why all those epicycles were in there. Sure, documentation can go stale, but even a slightly inaccurate accounting for the reason would have, at the very least, served as a clear reminder that a reason did indeed exist. Without that, there wasn't much to prevent them from falling into the perennially popular assumption that one's esteemed predecessors were idiots who had no clue what they were doing.

replies(4): >>42138653 #>>42138799 #>>42139332 #>>42143768 #
mandevil ◴[] No.42138653[source]
Hahaha, Joel Spolsky predicted exactly that IN THE YEAR 2000:

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

replies(2): >>42139178 #>>42142700 #
kazinator ◴[] No.42139178[source]
Times have changed. Code now does acquire bugs just by sitting there. Assholes you depend on are changing language definitions, compiler behavior, and libraries in a massive effort concentrated on breaking your code. :)
replies(4): >>42140087 #>>42140153 #>>42140245 #>>42144174 #
1. acheong08 ◴[] No.42140153[source]
Golang really is the best when it comes to backwards compatibility. I'm able to import dependencies from 14 years ago and have them work with 0 changes