Software development topics I've changed my mind on

Greenfield, absolutely design up front you lucky devils, but iterative is the way otherwise.

I'm am the "Dave" on my current code since I was one of the first engineers on the project and the others before me have long moved to management. There is a lot I don't know about how the code works. There are dark corners we just lifted completely from an earlier project where the guy who wrote it 30 years back is retired. This is normal.

I'm fighting desperately to keep this code in shape as I don't want to go to management to ask for $$$ (billions) to rewrite it. I regret many choices. I'm making other choices in response that I fear someone will regret in 15 more years. I'm hoping to retire before then - better talk to me now because soon the people who have talked to the person who wrote the code 30 years ago will also be a memory. (the guy who write the code 30 years ago is still alive and someone has his phone number - they talk once a year about something weird to see if why is remembered)

Iterative work in a large legacy codebase is how you end up making your large legacy codebase larger and even less understood.

Your planning should "wade into the code" from the start. I have always gotten better results by charting out flow diagrams and whiteboarding process changes than just "diving in and changing stuff".

Frankly, I'd say it's the opposite for greenfield development. Doing iterative work to build out a new product and make changes as you discover needs you didn't account for makes a lot more sense that flailing around making holes in something you don't fully understand that is tied to active business needs.

In terms of a broad population, I am not sure there is a meaningful difference, though. You can iterate on your ideas on the whiteboard or you can iterate on your ideas in code, but the intent is the same. Either way you are going to throw it all away once you have settled on what should be the final iteration anyhow.

It just comes down to where you are most comfortable expressing your ideas. Some like the visuals of a diagram, others are more comfortable thinking in code, some prefer to write it out in plain English, and I'm sure others carry out the process in other ways. But at the end of the day it is all the same.

I think this needs to be highlighted, because while I completely agree, I think it's often implicit, taken for granted, and neglected. Far, far too often I've seen code bases bloat because this never takes place. The sentiment at a lot of places seems to be, if the tests pass, ship it. Arguably, it may even be the right decision.

Ultimately what matters is the final changeset. How you get there doesn't really matter.

unless you have the old maintainer on call (I rarely did due to them leaving the company years ago) you definitely need to move slowly. rely on test suites if you are blessed with them. Submit small changes that pass tests.

BTW, nice and timely username.

Junior dev made to maintain some code base: "wtf, all this old code suck. People were really bad at their job".

Same dev 5 years later: "wellll, this looks bad but there must be a reason.". Usually the reason is someone sold a new feature without asking the implementers or even checking what the impacts could be. So it has to be ready yesterday and you'll never get approval to refactor or clean-up anything, until it breaks.

That only works for greenfield projects where you have extensive experience with everything that is going to be used on that project. For all others you still learn as you go and all plans and designs need to be revalidated and updated multiple times.