I’m having a hard time squaring the circle of “consensus based design doesn’t work for software but it does work for cars.” By all accounts, here in the US, we regularly bounce software architecture decisions around a room and land on a best design based on inputs from many. Likewise, our cities and cars are founded upon (id even say drowned by) consensus based design.
Maybe I’m misunderstanding the thesis here, but it seems contradictory. I do think PG has a point with an ingrained culture of quality being hugely important. I just don’t think that necessarily contributes to bad software. In fact, I’m quite certain it doesn’t, since companies like Nintendo manage to produce absolutely beautiful pieces of software regularly.
In the US, consensus would be achieved through brainstorming, open debates, etc. and at the end maybe a vote, or maybe the leader just says "let's try it my way, and if it doesn't work we'll do it your way."
In a Japanese company, people in general do not speak openly in meetings, because they are afraid of disrupting group harmony. Ideas need to be circulated in a series of one-on-one discussions--this is called "newashi" (https://en.wikipedia.org/wiki/Nemawashi). This means that for a group of N people, it's N*(N-1)/2 private discussions that need to happen. And everyone needs to be in agreement and comfortable that the idea is "right", and that there is nothing the slightest bit off with it. Only after all these discussions have happened and everyone is fully bought-in, there is then a meeting to "rubber stamp" the idea.
Don't know if it still works the same way, but "rubber stamping" used to be real - everybody would stamp a document with their 'hanko' [0] (name stamp). Those who were not completely on board would make their stamp at a slight angle.
What is "bad software"? It is not software that has bugs. It is software that does not do the right thing. Any amount of money and effort invested in SW quality and process quality is simply wasted if the software does not do what its users need it to do.
Now tradition prioritizes quality. Do it the right way, like it always has been done. Tradition is not a good ingredient for software industry. If your motto was write software "like it has always been written" you are missing the boat because there is no need to write the same program again and again.
There's no reason to write the same software again - because then you could just use old existing code instead of retyping the same characters again in your editor. Déjà vu. Groundhog day.
Software allows more gradual consensus-building throughout the product lifecycle, while car companies have to reach consensus earlier and between more stakeholders simultaneously.
Maybe I’m misunderstanding the thesis here, but it seems contradictory. I do think PG has a point with an ingrained culture of quality being hugely important. I just don’t think that necessarily contributes to bad software. In fact, I’m quite certain it doesn’t, since companies like Nintendo manage to produce absolutely beautiful pieces of software regularly.