Recently I read some article about
Cynefin framework, it is really inspiring. As the diagram shows, cynefin framework categorize the problems in to 4 domains:
- simple
- complicated
- complex
- chaotic
For different domain, the approach and strategy are quite different.
Today I would like to analyze the software code using cynefin framework.
Which domain does software belong to?
In General I will say software belongs to complex domain. One reason is software product environment changes so fast, the other reason is its entropy nature: always grow from simple to complex. Software product is so hard to predict and plan. That is the reason why we choose agile methodology: we follow TDD, keep refactoring, iterative developing and continuous integration. These methods are to deal with rapid the software's rapid changing context.
Let's compare the complex domain with agile practices:
complex, in which the relationship between cause and effect can only be perceived in retrospect, but not in advance, the approach is to Probe - Sense - Respond and we can sense emergent practice.
Here The
probe - sense - Respond is same as TDD and iterative development, since we don't understand the domain, so we have to rely on immediate feedback.
And the emergent practice and retrospection, which is the same as refactoring, refactoring itself is emergent practice.
We can also conclude that the reason why waterfall does not working is because they assume the problem domain in software is always in simple domain.
How about other domains?
If we don't care code base and let it grows, then code base will becomes more and more complex until it becomes chaotic. As a developer we all have the experience of working with messy legacy code base: the messy code is hared to understand, hard to maintain; you fix one issue, then will generate another issue unexpectedly; the software is unstable, a small change will cause a big issue; the issue is always unpredictable;nobody understand the system; we spent all the time putting fires. Which is totally unstable and uncontrollable. These symptoms fit nicely with the chaotic domain model.
But if we keep writing clean code, the code are easy to understand, easy to maintain, easy to change. In agile world writing clean code also means simple design. So this will fit nicely in simple or complicated domain. Since they are both ordered. so they are manageable and controllable. That is software's ultimate goal - flexibility, maintainability and reusability. So we will say clean code will help the software reduce the complexity.
Why clean code will help reduce the complexity?
The following tools and method help us writing clean code:
- SOLID principles
- high cohesion/loose couple
- Design patterns
- DRY principle
- LoD principle
- Refactoring
Lets' dig them deeper:
-
Break the unnecessary dependencies
Uncle Bob once said writing software is all about dependency management. SOLID principle, high cohesion/loose couple means reducing dependencies. We all know that the more interactions between objects, the more complex the software will be, so reducing the dependencies means making the software simpler.
- Set Rules and Constraints
Design patterns basically is describing the rules of the relationship between objects in a specific context. To make software reusable, stable and manageable, we do not allow objects interact each other randomly, they have to follow certain rules. This is quite similar in human society, we have to maintain the orders via laws, rules or regulations.
- Encapsulate changes
One of the advantage of design patterns is how it deals with change: encapsulate changes. Which means when we identify a concept which it changes, then we encapsulate it by putting it into a class. we don't want them randomly change. we put them in a box, isolate them. Once we put those details evil in the box, then we can understand or control the system by using abstraction. Then the system becomes stable, manageable and controllable
Conclusion
- In General software belongs to complex domain. The agile practices are the right practices to solve the complex domain problems;
- Writing clean code will help us reduce the complexity, will move from complex to simple/complicated domain;
- Writing messy code will increase the complexity, will move from complex into chaotic domain, this is what we are trying to avoid.
Strategy
So our strategy will be constantly refactoring our code base, keep code clean, avoid messy code.
Resources
