Design docs at Google are informal documents that are used to define software designs. They serve the purpose of early identification of design issues, achieving consensus, ensuring consideration of cross-cutting concerns, scaling knowledge, forming an organizational memory, and acting as a summary artifact. Design docs should include a context and scope section, list out the goals and non-goals, provide the actual design with details, discuss alternatives considered, address cross-cutting concerns, and be of a sufficient detail but also short enough to be read by busy people. They should be written when the solution to the design problem is ambiguous and there is a need for organizational consensus, involvement of senior engineers, consideration of cross-cutting concerns, and documentation of legacy systems.

10m read timeFrom industrialempathy.com
Post cover image
Table of contents
Anatomy of a design doc #When not to write a design doc. #The design doc lifecycle #Conclusions #
1 Comment

Sort: