I think something people need to be aware of is that the engineering culture at places like Google is extremely different than, say, a bank.
Design docs work well for Google because it has decentralized, independent engineering teams composed mostly of reasonable people, with few or no mandates from outside their teams. They tend to fail at companies with underperforming, micro-managing, and/or overreaching teams (e.g. unionized project managers that have literally nothing to do, bizdev telling developers what features to implement (down to specifics), QA teams who are incentivized to find "flaws" ad-infinitum to look busy, etc).
But I see this as a symptom of a fundamental dissonance in goals. Design documents are used by organizations whose goal is to build/change things. Many organizations are averse to change, and their processes reflect that, through overly microscopic documentation, convoluted approval chains, etc.
But I have become rather cynical about the motivations of a lot of organizations, these days.
Everyone seems to be promoting an environment where there's a constant circulation of relatively inexperienced (not always low-paid, but inexperienced) developers, staying at companies for short periods of time, then moving on.
This requires a codified, ingrained structure that needs to be documented and supported. It applies to modern, "agile" companies, as much as it does to more traditional, "hidebound" corporations. People that come in need to be onboarded quickly, squeezed for every ounce of productivity possible, then let go, when they are no longer useful.
This is supported by the employees, as much as by the managers. The salaries can be quite high; especially for people that are quick to adapt and come up to speed.
But there is absolutely no substitute for an experienced, cohesive team that has developed a shared vocabulary and focus.
I was fortunate to be a member of such a team. The person with the least seniority on the team had a decade. Everyone had over 30 years' experience in software development, and we got some fairly intense stuff done. Sadly, we were still subject to the kind of structure I mentioned above, and a lot of our product ended up being housed in substandard wrappers (we did "engine" code).
>I think something people need to be aware of is that the engineering culture at places like Google is extremely different than, say, a bank.
I have to say that this is not uniformly true, I've worked for a few financial institutions, and usually follow some sort of design process before embarking on any sizable work (as mentioned above, I find the RUP process to be a really useful framework). More often that not the design process is usually welcomed because people are happy that someone is willing to create a holistic view of the problem (from stakeholders down to db schema and class diagrams). The process helps with project management, identifies stakeholders and describes the support requirements after transition to prod.
Banks actually love somebody to detail all that.
In a few cases I'm aware of, my design docs are still referred to years after I've moved on since they capture the most important thing that everybody forgets - basically the 'why' that certain decisions were made, and the alternatives rejected.
A good architecture diagram never goes out of date either :)
Design docs work well for Google because it has decentralized, independent engineering teams composed mostly of reasonable people, with few or no mandates from outside their teams. They tend to fail at companies with underperforming, micro-managing, and/or overreaching teams (e.g. unionized project managers that have literally nothing to do, bizdev telling developers what features to implement (down to specifics), QA teams who are incentivized to find "flaws" ad-infinitum to look busy, etc).
But I see this as a symptom of a fundamental dissonance in goals. Design documents are used by organizations whose goal is to build/change things. Many organizations are averse to change, and their processes reflect that, through overly microscopic documentation, convoluted approval chains, etc.