- Late-bind on designs.
The goal of the design process is not to generate a single point solution, but to instead characterize the design space for a given problem: a single point should then fall naturally out of that space given the problem constraints. Converging early on a single design is harmful; the team should have the ability to jump from one part of the space to another right until a solution is picked.
- Each point solution is a DoS attack on the design process.
Talking about individual designs in isolation slows down design. Talking about designs in the context of the design space accelerates design. New designs should be described in terms of the design space, so you can immediately convey their relative position compared to other point solutions.
- 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.
- Talk about the problem, not existing systems.
- Solution Complexity » Problem Complexity
- Solution Bias
- Always talk about a second application.
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.
- For each abstraction, build one implementation; plan for a second; hope for a third.
In the opposite direction, you don’t want the abstraction’s semantics to rely on its implementation details. One way to ensure this is to talk about multiple implementations in the design process.
- Abstraction is not free.
Abstraction is a balancing act between two types of complexity: the complexity of concreteness and the complexity of abstractness. Each time you add a layer of abstraction, have a precise characterization for why it has to exist, as well as the division of functionality between this layer and the ones around it.
- Be critical (but about the right things).
One way to approach design is to continually de-risk the pieces that are truly unknown; while deferring work on the pieces that are difficult but known. (In the opposite direction, researchers need to be more focused on details and practicality, but this happens naturally in an industry environment).
mahesh's blog: What we talk about when we talk about System Design.