“No design” fallacy
Have you ever travelled on an old road? What’s interesting about that road? It often takes dips and turns that seem almost unexpected. It’s uncomfortable. Why did this all come about? Who designed this particular road?
You know what happened in many cases. That road started out as a cart path, as a means for a few people to travel to reach some destination. It had a purpose, but it had a very narrow purpose. What happened over time? More and more people started taking that cart path. Perhaps the way got broadened a bit. And then, eventually, someone added pavement to that cart path, but it still followed that cruft design that its original users created.
What’s the difference between that old cart path that became a road, however uncomfortable it is today, and a superhighway? The difference is that the superhighway had the intended design. It was led to its completion through a lot of research, through a lot of design, through careful engineering. That expressway, that superhighway is more or less a pleasure to travel, when at high speeds you can turn a corner comfortably without hitting the brakes, whereas, on that old cart path that has now become a road, you’re probably going to wear your brakes out soon if you travel that road often. It’s uncomfortable. It’s even dangerous in some places.
Software development can be designed from the same perspectives. It can either be like that cart path that eventually turns into a paved road or a well-designed, well-thought-out, well-engineered road that’s comfortable and relatively safe to travel. Remember that effective design will lead to such software metaphorically. And so this is the kind of path that you need to design for your business.
~ Explained by Vaughn Vernon in Domain-Driven Distilled Live Lessons
There is nothing called “no design”. Either the design can be good and effective, or it can be bad. No design is a fallacy. The Result will be a bad design if it is an afterthought.
We tend to follow “the task board shuffle”. It is the routine of moving the assigned task from “To-do” to “In Progress” and finally to “Done”. Sometimes this happens due to time pressures, but that is not the case always.
Knowledge acquisition and exploration
Knowledge acquisition is an activity that should occur while moving a task from one column to another. The team should acquire knowledge [about the business, the customers] to build a product that delights its customers.
Nick Tune in his talk — Domain-Driven Design: Hidden Lessons from the Big Blue Book — refers to the lack of importance developers give for exploration and having insights.
Effective Design
As Vaughn Vernon says, a business cannot excel at everything. For, e.g., an insurance company is expected to be the best in a particular area of insurance. The company need not have to be the best in databases or frameworks or in accounting. It is hardly of any use if an insurance company excels in other areas without being the best in its core domain — the insurance.
An effective design is a design that helps the business to excel. And effective design happens when the developers understand the market and create a model that matches the core business.
Finally, the effective design doesn’t happen overnight. It happens through continuous discovery through customer collaboration.
Initial models are usually naive and superficial based on shallow knowledge.
The refactorings that have the greatest impact on the viability of the system are those motivated by new insights into the domain.
~ Eric Evans — Domain-Driven Design
