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
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.
Chapter 7. What Is Agile Design?
© Jennifer M. Kohnke
After reviewing the software development life cycle as I understood it, I concluded that the only software documentation that actually seems to satisfy the criteria of an engineering design is the source code listings.
Jack Reeves
In 1992, Jack Reeves wrote a seminal article"What Is Software Design?"in the C++ Journal.[1] In this article, Reeves argued that the design of a software system is documented primarily by its source code, that diagrams representing the source code are ancillary to the design and are not the design itself. As it turns out, Jack's article was a harbinger of agile development.
[1] [Reeves92] This is a great paper. I strongly recommend you read it. It is included in this book in Appendix B on page 687.
In the pages that follow, we often talk about "the design." You should not take that to mean a set of UML diagrams separate from the code. A set of UML diagrams may represent parts of a design, but those diagrams are not the design. The design of a software project is an abstract concept. It has to do with the overall shape and structure of the program, as well as the detailed shape and structure of each module, class, and method. The design can be represented by many different media, but its final embodiment is source code. In the end, the source code is the design.