I confess to having said, “I wouldn’t have done it this way.” The phrase seems like a polite way of trashing the current system architecture while implying that you know the correct design.
You might get a snicker and feel smart and clever, but you’re creating problems for yourself and your project.
It puts the original programmers on the defensive.
You may be politely trashing their design, but you’re still trashing their design. Instead of listening to you describe your superior solution, the original programmers are going to be thinking of arguments defending their work.
The Business People Don’t Care
The managers and executives in the room didn’t care about how the original programmers designed the system. They don’t care about how you would have designed the system. They want to know what you’re going to do about their business problems.
It leaves the listener questioning your intent.
Are you changing the design because you don’t like it, or because it needs to be done? You never want anyone wondering if you are proposing a refactor or rewrite because of style.
Your way might not be possible
I once used PostgreSQL as a noSql system because all the other AWS options had row size limits that were too small. For years after new developers would tell me that I should have used different technologies. I would explain the size constraint, and more often than not, show that AWS still had constraints that would prevent us from using the technology.
Instead of trashing the original design, try these two approaches instead:
Talk about the business problem with the current design.
“The current design won’t scale to the levels we need.” Maybe it won’t scale because it was a bad design, maybe it was a massively successful MVP. Either way, you need to replace it to go forward.
Be positive
“The current design was a great way to get started.” If the original design was an abject failure, no one would be asking you to rebuild or expand it. Acknowledge that, whatever its shortcomings, the original design moved the business forward.
Acknowledge your ignorance
“I don’t know what the original requirements were, but the current design isn’t a good fit for our needs”. It’s useful to know why past choices were made so that you don’t miss requirements, and people are much more likely to tell you if you’re the first to admit you don’t know.
“I wouldn’t have done it this way” is an old developer cliche. The developers who inherited your work are probably saying it about you right now.
