[jahewson]

This is so true. It still shocks me and I don’t know why. The most frustrating version for me is when the original author of a solution didn’t care all that much and would admit it was a hack but they’re no longer around - and their successor thinks that what they’ve inherited is some sort of sacred object built on infinite and unknowable wisdom. So this obvious design flaw must actually be a carefully designed feature that were simply not capable of understanding. Maddening.

[hashmush]

I try to always add comments to such code that explicitly says exactly that. Something like:

> This is a best effort hack based on X and Y. It might not be 100% correct. Feel free to improve it.

> - Name, 2023-08-05

[mcherm]

That sounds like a WONDERFUL practice!

[waynesonfire]

I hate you and I don't need your permission.

[jkingsman]

It's especially difficult, too, because the stagnancy is often (hopefully) based, for better or worse, in humility, which is broadly a good trait to hav. Especially around Chesterton's Fence and product decisions, moving carefully and respectfully for prior art is a generally safe and mature way to work.

But dangit, sometimes you need to trust that you have a better solution and just execute! But it's not that easy.

[ehnto]

First step to solving that problem is letting people dive deep into codebases, so that they can understand the situation. Which requires having that time available to them, rather than always being on busy work. I think people sometimes lump this in with maintenance, but it is something different and worth putting into your estimates. Add time to grok the existing solution first, not just time to build on top of it.