Good Software Development Habits

Seems like the definition here of software is always “maintenance” of something as is, like replacing the boards on Theseus

Sometimes software is hard and 10x engineers just need to rewrite the whole thing or replace large systems

To subscribe to some world where we have to do that in “small changes” limits us

We shouldn’t make process to the weakest engineers

Even if you're a "10x engineer" the ability to describe how you would fix or replace things using just small changes is extremely valuable. And the inability to put together a moderately-detailed plan for that is a big smell.

If you don't actually understand the full set of changes that will be required in order to get to your desired new end state, how can you evaluate whether "just write the whole thing" is a one month, six month, or longer project? There are going to be nasty edge cases and forgotten requirements buried in that old code, and if you discover them for the first time halfway into your big rewrite... you might suddenly find you're only 10% into your big rewrite.

(Especially if you're a "10x engineer" you should understand what makes big rewrites hard and often fail or go way over schedule/budget. You should've seen it all before.)

Why rewrite then? We should have only the strongest engineers, only those able to understand and thrive in any kind of spaghetti.

I've dealt with both: 1. maintenance coding 2. re-write coding

Re-writes take forever, because a lot of the edge cases and bug fixes are lost [1]. You might think they go away, and some do, but new ones are introduced. QA process is critical. Management becomes critical of excuses, and the longer the project is drawn out, the more they get involved. The final shift to a new system is never one-and-done. Management is paying for two systems, canary deploy.

Smaller re-writes are the ideal practice, and your code base is set up this way already, right?

Maintenance code is cheapest.

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

My experience tells me that it's both faster and higher quality to do things in small steps than leave it with your "10x engineers" (everybody thinks they are the one, right?) to "just" rewrite from scratch — and I've got plenty of proof in my close-to-20-years of career (I've never seen that go smooth; I've been a part of dozens of iterative "replace large systems" that were pretty uneventful).

As for the "weakest" engineers, even the "strongest" engineers are weak sometimes (bad day, something personal, health issues, sleep deprivation...).

I think it's misleading to say iteration or full rewrites are the only 2 options. The most impactful, yet successful, projects I've worked on rewrite a part of a system. ie replace a custom search index by Solr, but leave the data itself and the UI the same, then once you're happy that went well, improve the data or the UI afterwards.

I don't think it's a matter of making process for the weakest engineers. It's more likely that we're trying to apply one monolithic process to highly variable work.

You hit on something super important that I don't see discussed often enough: Different phases in the software lifecycle require different approaches. Trying to apply "maintenance mode" to a greenfield project (or vice-versa) can be a disaster for the reason you mentioned - sometimes you just can't break the job into small changes until you have something concrete to change! There is time for principled slow change, and there is a time for rapid prototyping. But most teams use a single process for both.