If agility is about building software in tiny increments, how can you ever design the software? How can you take the time to ensure that the software has a good structure that is flexible, maintainable, and reusable? If you build in tiny increments, aren't you really setting the stage for lots of scrap and rework in the name of refactoring? Aren't you going to miss the big picture?
In an agile team, the big picture evolves along with the software. With each iteration, the team improves the design of the system so that it is as good as it can be for the system as it is now. The team does not spend very much time looking ahead to future requirements and needs. Nor does it try to build in today the infrastructure to support the features that may be needed tomorrow. Rather, the team focuses on the current structure of the system, making it as good as it can be.
This is not an abandonment of architecture and design. Rather, it is a way to incrementally evolve the most appropriate architecture and design for the system. It is also a way to keep that design and architecture appropriate as the system grows and evolves over time. Agile development makes the process of design and architecture continous.
How do we know how whether the design of a software system is good? Chapter 7 enumerates and describes symptoms of poor design. Such symptoms, or design smells often pervade the overall structure of the software. The chapter demonstrates how those symptoms accumulate in a software project and explains how to avoid them.
The symptoms are:
Rigidity. The design is difficult to change.
Fragility. The design is easy to break.
Immobility. The design is difficult to reuse.
Viscosity. It is difficult to do the right thing.
Needless complexity. Overdesign.
Needless repetition. Mouse abuse.
Opacity. Disorganized expression.
These symptoms are similar in nature to code smells, but are at a higher level. They are smells that pervade the overall structure of the software rather than a small section of code.
As a symptom, a design smell is something that can be measured subjectively if not objectively. Often, the smell is caused by the violation of one of more design principles. Chapters 812 describe object-oriented design principles that help developers eliminate the symptoms of poor designdesign smellsand build the best designs for the current set of features.
The principles are:
Chapter 8: The Single-Responsibility Principle (SRP)
Chapter 9: The Open/Closed Principle (OCP)
Chapter 10: The Liskov Substitution Principle (LSP)
Chapter 11: The Dependency-Inversion Principle (DIP)
Chapter 12: The Interface Segregation Principle (ISP)
These principles are the hard-won product of decades of experience in software engineering. They are not the product of a single mind but represent the integration of the thoughts and writings of a large number of software developers and researchers. Although they are presented here as principles of object-oriented design, they are really special cases of long-standing principles of software engineering.
Agile teams apply principles only to solve smells; they don't apply principles when there are no smells. It would be a mistake to unconditionally conform to a principle just because it is a principle. The principles are there to help us eliminate bad smells. They are not a perfume to be liberally scattered all over the system. Over-conformance to the principles leads to the design smell of needless complexity.
