Hah, design docs at Google...<p>I read probably hundreds of deigns docs during my 6 years at Google.<p>I think among them, only a handful of design docs, like < 10, are considered clear, clean, and succinct. And all of them are more or less retrospective ones summarizing a system after it's already being implemented and running for a while.<p>The newer design docs, which are served as actual working documents for an active projects, are no doubt primarily a <i>process mechanism</i> to solicit design inputs, and garner supports from stakeholders.<p>It is a formality to show that the project owner is willing to <i>waste</i> his time and to convince so-called "reviewers" about the validity of the project. The reviewers usually do not read the design doc in earnest. Only the stakeholders, like the TL of the team, potential customers, partners, would spend serious time on them. It's more or less a debate ground for stakeholders to pointing fingers at the design process. That's also why the design doc is written in Google Doc in the first place.<p>Once a design is "approved", it usually means from most major share holders are satisfied, to everyone is wearied down enough and the project has enough importance to actually push forward, they are OKed for implementation.<p>After that the design doc is largely useless, the designs laid out in the doc is usually 1) too simple that there is no need to consult design doc anyway, one can explain it in a few minutes chat; 2) too complicated that the design diverges from the actual code that the design doc offers little guidance. And very few design docs sit in between.<p>All in all, anything produced during a software engineering project seems all is about being a tool for organizing the human interaction process, the artifact, aside from a very high-level motivational piece, and the end result code + docs, whatever in between seems largely bears little value after the work is done.