Design is not rules, it’s not patterns, it’s not technological choices or indeed code. Design is tradeoffs, driven by data where possible and gut instinct. It’s about identifying the core challenges of a problem domain (which might ultimately be one or many systems) and addressing them through creation of appropriate abstractions. These abstractions embody:
- Functions to be performed
- Data to be discovered, consumed and produced
- Non-functionals (e.g. SLAs)
The abstractions are then rendered into the real-world using appropriate hardware, technologies, patterns and languages. A good design:
- Exhibits few exception cases
- Has logic and/or data located neatly and predictably
- Applies a small set of core constructs repeatedly
- Addresses operational needs
- Considers cost versus value delivered
- Is as simple as possible
- Has the minimum of implementation assumption
There are several key failing points in the design process:
- No adjustment in the face of implementation feedback – No design is complete or perfect. There will always be missed details leading to brittle code, complex corner cases or convoluted solutions. It is critical that we monitor our progress and adapt the design accordingly.
- No up front design – Design is the skeleton upon which we hang technology choices and code structure. In it’s absence we rapidly descend into a world of difficult to navigate code and costly constraints set by uninformed product choices.
- No care in following the design – A key element of design is to place the right things in the right places. Failing to do this at code time increases coupling, makes maintenance difficult and can impact both performance and scalability. Similar effects occur as the result of poor technology selection.
Design and implementation go hand in hand yet many of us lack awareness of where the boundary between these two elements lies. We don’t understand how these elements interact with each other or appreciate the impact of decisions we make in respect of one element on the other.