>The goal is not to be right. It's to find what's right.

This is why I think design docs need to be lightweight and reviewed early. Design docs shouldn't be a masterpiece perfected in isolation over the course of days or weeks. That guarantees the author has calcified their opinions. When I was on review panels at Amazon, 99% of them were an exercise in futility -- the author had already poured concrete. It is very, very, very hard to avoid the mental trap of "Hrmph! I've thought about this more deeply than anyone else" that comes from living down in the isolated world of "doing design."

The earlier you get other eyes involved, the more likely people will actually listen to feedback and consider alternatives. You still, of course, need that heads down time to put in all the details, but the overall shape of the design shouldn't be a big reveal when you hit the design review.

So much this. Bouncing early design ideas (informally) off other stakeholders or at least more experienced engineers can save SO much pain. The reverse of that is true, too: giving early feedback on other people's designs can give them the insights THEY need not to inflict pain on YOU.

I think there is a risk of going too far in the other direction leading to design by committee. It’s often the case IME that a casual reader actually hasn’t thought through the problem enough to understand why their drive by feedback or alternative doesn’t make sense. A process that results in those things getting accepted may just be introducing more entropy into the design process.

Good comment. I think both of your perspectives are fair and manifest in the size of what is being designed.

Meaning that if someone designs something huge, end-to-end, it's going to be difficult for external people to address potential flaws within the design. A lot of interlinked parts requiring to have the full mental model loaded in the brain. So one should go step by step.

It's also true that not every feedback is equal and it's important to think in advance about how to address rebuttals since most people don't give in-depth feedbacks but surface gut feeling (which can be invaluable too, even if simply in terms of UX), unless they have wondered about how to solve the same exact problem before. That requires more time spent thinking about the design.

I had a wise friend tell me that engineers are always in a state of being wrong. What you build today you will most likely laugh at in five years. The goal for today is to build the least wrong thing you can. I used to argue more than I should have simply because I didn't like being wrong either. After hearing this, it helped me to become more objective.

My problem is that the least wrong thing I know of is very different from all existing processes, and take more time and money than most are willing to stomach.

Time and money are factors into wrongness, too. That's what differentiates software engineering from computer science.

Indeed, but then there is, "using a query language designed for data analysis in event sourced systems to: read, parse, version, and write system and configuration files instead of using VCS like Git" levels of wrong, and sales/marketing professionals in charge of the system wrong.

Time is measured in quarters, money is measured vaguely by proximity to sales.

Thought using excel as a database was bad? Try working in a system where strings are `eval`ed in SQL, and every state change is stored in intermediate or virtual tables, then thrown away, so no actual version control is taking place; just diffing and merging Unix configuration files.

Why not use diff and patch? Takes too much time and money, they only know SQL.