Don't see a really important one in my opinion: Refactor legacy code, don't rewrite it. All that cruft you see are bug fixes.

Because rewriting old complex code is way more time consuming that you think it'll be. You have to add not only in the same features, but all the corner cases that your system ran into in the past.

Have seen this myself. A large team spent an entire year of wasted effort on a clean rewrite of an key system (shopping cart at a high-volume website) that never worked... ...although, in the age of AI, wonder if a rewrite would be easier than in the past. Still, guessing even then, it'd be better if the AI refactored it first as a basis for reworking the code, as opposed to the AI doing a clean rewrite of code from the start.

▲

namenotrequired 3 hours ago | parent [-]

The “second system effect” page more or less covers this

	▲	computerdork 2 hours ago \| parent [-]
		Ah, think there is overlap, but still not the same in my opinion. Having read this just now, the second system effect seems to be more about not getting overly ambitious in the redesign. What the guideline I mentioned is saying is "don't rewrite, refactor."" As you probably know, there is a tendency when new developers join a team to hate the old legacy code - one of the toughest skills is being able to read someone else's code - so they ask their managers to throw it away and rewrite it. This is rarely worth it and often results in a lot of time being spent recreating fixes for old bugs and corner cases. Much better use of time to try refactoring the existing code first. Although, can see why you mentioned it from the initial example that I gave (on that rewrite of the shopping cart) which is also covered by the "second system effect." Yeah, thinking back, have seen this too. Overdesign can get really out of hand and becomes really annoying to wade through all that unnecessary complexity whenever you need to make a change.