# What We Talk About When We Talk About System Design - mahesh's blog Synced: [[2023_11_30]] 6:03 AM Last Highlighted: [[2023_07_23]] Tags: [[Software]]  ## Highlights [[2023_07_23]] [View Highlight](https://read.readwise.io/read/01h6168vgvrsk2ztgdren2t733) > ***Think in parallel; Design together; Implement in parallel; Review together***. Certain parts of the design and development process are creative and should be parallelized / sharded, while others require discipline and should be centralized / broadcast[3](https://maheshba.bitbucket.io/blog/2023/07/12/Design.html#fn:2) [[2023_07_23]] [View Highlight](https://read.readwise.io/read/01h6168ztb55s21vbk3gz7w5aq) > Thinking / brainstorming is a creative process and should happen in parallel with no coordination. [[2023_07_23]] [View Highlight](https://read.readwise.io/read/01h6169a0n8hgscehpw3phatfw) > Design should be centralized. The design space is (strongly consistent) shared state between team members; new ideas should be slotted into this space with synchronous coordination. [[2023_07_23]] [View Highlight](https://read.readwise.io/read/01h6169z13tc6nkr6s83qpbj3e) > Implementation can happen in parallel. After the centralized design phase, anyone should be able to implement any part of the design. Late-binding to developers is critical; it’s typical (and preferable) for the person implementing an idea to be different from the person who came up with it. Developers often get attached to ideas if they know they’ll get to implement it. [[2023_07_23]] [View Highlight](https://read.readwise.io/read/01h616ae25bwjjjsfdgcg9hbv9) > Reviewing should be centralized. The code base is shared state. API changes in particular have to be reviewed carefully by multiple people to make sure they are not one-way doors. In a healthy design process, Design and Review end up being centralized bottlenecks, which is okay. (In research, you have the same four steps; but the carefully reviewed deliverable is typically a paper rather than a codebase). [[2023_07_23]] [View Highlight](https://read.readwise.io/read/01h616anc9mqm85yxs8dd981mc) > [4] ***Talk about the problem, not existing systems***. It’s tempting to start the design process by looking at similar systems. This carries two types of risk: [[2023_07_23]] [View Highlight](https://read.readwise.io/read/01h616ewzrkmdtak887g2xjf29) > Practically, even if you are implementing only one app, it helps to always consider a second app (or even implement one in tests); to prevent application specifics from leaking into the abstraction [[2023_07_23]] [View Highlight](https://read.readwise.io/read/01h616f1a94nswkr0429e7rqzj) > *For each abstraction, build one implementation; plan for a second; hope for a third*