[tdumitrescu]

"Many teams in the industry constantly rewrite parts of their code. Not because they keep figuring out better ways of approaching the problem but because nobody on the team has an accurate mental model for how it works and how the code fits in with the rest."

This part rings very true, as someone who's been through plenty of rewrites / "make module X not suck" projects. A side observation here is that usually the original author (sometimes long-departed or departing) understands very well the limitations/flaws of the original system/implementation, but can be excluded from the design of the replacement for any number of misguided reasons. Trying not to bruise the ego of an early employee, thinking that they wouldn't agree with any changes, whereas those are often the people in the best position to guide a rewrite, and often would love the chance to fix some of the decisions they had to make originally.

[sdiupIGPWEfh]

> A side observation here is that usually the original author (sometimes long-departed or departing) understands very well the limitations/flaws of the original system/implementation, but can be excluded from the design of the replacement for any number of misguided reasons.

I relate to this so much. I'd offer an open letter to some poor anonymous soul who inherits one of my dumpster fires. Because I'll certainly never be given the chance to revisit anything.

Yep, my shit's broken. It was written long ago, under different constraints, for a different audience. I made the best trade-offs I could. I documented them! Though you'll probably never find my writings, and if you do trip over them, you won't understand them yet. Today, I'd scrap most of it if given the opportunity. But to whomever is now taking on the rewrite, you know that little nugget at the core which perplexes you so? The one that doesn't fit your mental model of any type of programming you've touched in your career? That there is the core value proposition that makes it all possible, and if you throw that out, you've doomed yourself to learning my wisdom the hard way. If you're at all up to the task, then the next few years of your life and the remainder of your days at this company will be spent fixing the same problems by reading the same papers and obtaining the same obscure domain knowledge. No, it can't be abstracted away. Yes, it's fundamental. No, no one else will really understand it either when you try to explain it, because no one else without the accountability you now have will sink enough of their time into building the mental model you've had to construct. Good luck.

[mansoon]

Why do we bother?

[sdiupIGPWEfh]

On a good day, I'd say we do it because it can be fun and rewarding. It's an escape from the regular daily grind; something beyond the drudgery of say React, CRUD, the frequent silliness of business logic requirements, or whatever the mundane might be at your own workplace. It can also earn us the respect of those peers whom we ourselves respect the most. A knowing smile and a nod between us is priceless. Maybe we each count ourselves lucky that at least we were spared the other's tribulations.

My own efforts don't quite earn me "the big bucks" that I read about at companies I'll actually never work for. Just a respectable east coast income that I shouldn't complain too much about. Don't know that I'd be happier anywhere else anyway. The bills get paid while I'm making the world a better place.

On a bad day, I'd say we do it because we're suckers for punishment. It's in our nature.

[layer8]

This is very true. On multiple occasions, after taking over ownership of code for which the original author wasn’t available anymore, I ended up rewriting it bit by bit, according to my progress in understanding it. In some ways, rewriting a piece of software is the best way to understand it deeply, and/or to uncover the gaps in one’s understanding.

[cudgy]

> In some ways, rewriting a piece of software is the best way to understand it deeply, and/or to uncover the gaps in one’s understanding.

Fine, so long as your rewrite is not checked in. Otherwise, this approach will surely lead to chaos when prior developers who figured it out now have to re-learn your version, resulting in the exact problem this article is addressing.

[layer8]

I explicitly mentioned this is in situations where the original authors aren't around anymore, and hence you're on your own figuring out and maintaining the code.

[cudgy]

It is the case for most code that the original author is gone. However, there are likely to be other developers around that have encountered the code or maintained it in the past.

Rewriting and submitting code mainly because one does not understand the original version is usually not a good idea; understanding the original code should typically be a prerequisite to replacing it with other code. Otherwise, how would the developer know that the new code was better?

[robertlagrant]

I agree. I would add that sometimes the existing team only want to make incremental changes to their existing software, rather than make something new, and that can make team dynamics... complicated!

[yashap]

I’ve heard Google are quite rewrite heavy, as an intentional strategy. Not that they rewrite everything all the time, but that they’re quite open to rewriting significant sized systems, and do it quite a bit more than most tech companies.

Not sure how true that is, or if it’s more myth. Also not sure how common it is to have original devs participate in the re-write, or if this is more something they do if the original devs have moved on. If any Googlers on HN could chime in, I’d certainly find it interesting!

[mansoon]

2 systems: One that you’re supposed to use, that isn’t finished; one that’s already deprecated.