Mistrust in Applicability: Design, Testing, and Refactoring

Design

People sometimes fear that a system will not be designed if the team follows an agile process. This is inaccurate; of course the system will be designed. However, with agile projects, the design is often expressed differently than people expect.

Generally, each design has different views. These different views are expressed with different notations. For example, the most common views are those expressed in source code and UML. Because these are just different views of the same thing, design or modeling is rarely explicitly mentioned in this course. Therefore, whenever something is implemented, there is an implication that it has been designed, which in turn means it was modeled in some way and coded. So, code often gets created after the design has been modeled using, for example, UML as the modeling notation. Therefore, the design might be modeled on different levels and expressed with different notations, but this has no impact on the big picture or the progress and success of the project. The main goal is to produce running software, not documents.

UML documents often have the same problems as all other documents: they are seldom complete and rarely up-to-date. We can decide if this is a problem: the UML document has fulfilled its purpose—it helped team members develop a proper design. If, let’s say, the design changes and this change is only reflected in the source code, not in the UML document, this shouldn’t be a problem because the UML document has already served its purpose and no longer contributes anything to reaching our goal. Or, as Scott AmblerCanadian software engineer and author of multiple books about Agile, UML, and CMM. put it:

“Once a model has fulfilled its goals, you should stop working on it—you are finished!”

He continues later on, saying:

“You should update an artifact such as a model or document only when you need to when not having the model updated is more painful than the effort of updating it.”

If, for some reason, an up-to-date UML document is necessary:

• Do not insist on updating all the UML documents along the way. Motivating people to do this will be difficult, as it has no immediate purpose and does not help produce working software.
• Instead, look for a tool (or write a script) that will always produce a current UML document from the existing code. This will give a graphical view of the actual design.