Comment by ninkendo
8 hours ago
People look at the backlog of issues, see all the things they don't like about $subsystem, and think to themselves "we ought to rewrite this". The incentives are all aligned to make this common. Project managers get a nice chunk of work to manage, engineers get to write things their way, managers get a nice thing to add to their accomplishments, everyone feels like progress is happening. Heck, sometimes there may actually be real deficiencies in the existing code that are being addressed! And in the end, the bug count is lower! (Never mind that it's only lower because it hasn't had the time in production to actually find the bugs yet...)
Large-scale software is hard. So hard nobody's really managed to do it well. By large-scale I don't mean "a lot of users" or "a large deployment"... I mean "a lot of engineers". Once the number of engineers gets large enough, they start making decisions that make the product worse, more bloated, more buggy, and no human is capable of keeping it in check, because the sheer amount of activity in the code is so large you can't possibly keep up with it. And the worst part is that orgs try to solve this by... hiring more engineers to wrangle the complexity. By this point you're already sunk, there's no going back.
Why not have a "rewrite policy", criteria for when a rewrite makes sense or doesn't? Surely a random engineer can't decide to rewrite things on his own.
There’s too many people with incentives to rewrite. It keeps all the gears turning, keeps everyone employed. You certainly need to justify any rewrites, but… people are really good at justifying rewrites.