this quote is the most valueable :) “At the center of that decision lies whether the solution to the design problem is ambiguous–because of problem complexity or solution complexity, or both. If it is not, then there is little value in going through the process of writing a doc.”
A good overview of how software design docs are used and written at Google: https://www.industrialempathy.com/posts/design-docs-at-google/ … . A recommended read. At Uber, we have a similar approach, previously called RFCs, now ERDs (Engineering Review Docs). Some interesting parts from the article:pic.twitter.com/xTj2yJxCTi
-
-
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Interesting to note that code per se isn't what the company is after. Rather a solution which can be coded using any programming language. According to the document but I have came across the same thing. Solution not code per se.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
The "system-context-diagram" is really powerful, and not leveraged enough IMO. By showing the surrounding domain and proposed/new context, it creates immediate cognitive alignment. Do you use ADRs in addition to ERDs at Uber? And if so, how do they complement each other?
-
We use ERDs that are very similar to what is shared here. Usually plenty of diagrams. I wrote about it a while back, and it still works similarly: https://blog.pragmaticengineer.com/scaling-engineering-teams-via-writing-things-down-rfcs/ … IMO the comments & collaboration are underrated. We have *so* much discussion on these docs! (We use GDocs)
- Show replies
New conversation -
-
-
once called DUCKs
-
Before my time! I only read some DUCKs, it was RFCs when I joined
End of conversation
New conversation -
-
-
I'm an advocate of this approach to documentation. Though our team's focus now is placed on keeping docs updated (and relevant) as requirements and context changes
-
Found these two to be separate things. The design docs I see (and what Google seems to do) are just the point-in-time when designing the system. They’re usually not updated after. A systems documentation that is always up-to-date would be a different doc, with different focus.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.