Earlier quoted context omitted.
This is something that should be taught to folks while they're still in school. The "blueprint analogy" has baked in the idea that there's a "design phase" and a "construction phase" and that these are often discreet parties. Nothing could be more incorrect when it comes to software. In software, the design is the code. The compiler/interpreter are the construction of the system.
> In software, the design is the code. The compiler/interpreter are the construction of the system. That's IMO a pedantic view. Yes, ok, but when I design software I describe it's high-level characteristics, more like describing the plot of a book than the specific words in a book and the what the characters say to each other. I'd say there are many levels of design. Code is the last.
Re: Design Docs at Google
#191Your design can look very good yet be seriously flawed when you actually write the code. Designs (blueprints) civil engineers use are based on many years of practice that are enshrined in engineering codes sometimes going back thousands of years. Key issues in the design like the way forces interplay, are amenable to mathematical analysis. The only checking we can do of UML-like diagrams and written "specs" is peer review. Not the same at all.