Agile Design

INTRODUCTION

As a developer, I've always been fascinated by software design. Usually defined as the activity to specify software components (classes) and its interactions, I consider it both interesting and challenging. When I first get in touch with agile principles (SCRUM and XP in particular) I realized that there is a huge gap between what I learned back at college and what the methodologies enforce.

UP FRONT DESIGN

I learned back at college that design is the software engineering phase that bridges requirements specification and the coding. The analyst defines WHAT to do, the design HOW to do it and the programmer just DO it. The design phase products are documents and diagrams to be used by the programmer to code the software as the analyst idealized it. This approach is called up front design and it doesn't come without its drawbacks and challenges.

• It is very hard (if not impossible) to come up, in advance, with such a design that both meets all requirements and is flawless.
• It would be necessary to come up with a design so flexible to accommodate the dreaded change of requirements. Even if possible, what would be the cost, in terms of complexity, of such design?

With SCRUM there's not such thing as design phase. There's a meeting when the product owner detail the sprint backlog items so the analysts can start documenting, the testers can start write tests cases and the developers can start coding. That simple. There's no design at all? Well, not as I learned back at college.

EVOLUTIONARY DESIGN

If its not possible to come up with a design that meets all the requirements, that is flawless and its impossible to avoid requirements changes, what could justify the effort (usually a big one, considering the complexity and level of abstraction required) spent with an up front design? Accepting that coding is design, agile methodologies come up with an approach called evolutionary design.

With that approach, design and coding walk side by side. The design evolves according to the functionalities been developed needs. There's no a formal role as designer nor a particular moment to do the design. Every developer design and redesigns every day.

YAGNI

One of the most intriguing concepts related to evolutionary design is known as YAGNI (You Aren't Gonna Need It). “Always write only the code you need right now, never the one you thing you're gonna need tomorrow.” Even when you are absolutely sure you're gonna need the code and the cost of implementation is zero: just write it when you actually need it.

YAGNI is counter-intuitive because it goes against what is believed to be the greater benefit of a good design: anticipation of complexity and consequent risk mitigation. Nevertheless, there are very good arguments in favor of such approach:

• Respects the clients ROI: write code that doesn't aggregate any value to the functionality under construction means to disregard the PO prioritization and , in consequence, the client's ROI.
• Time saving: Time used to write code that is only going to be used in a later iteration may be missed when it comes to deliver the functionalities promised to the actual iteration.
• Possible changes: To write code in advance is unnecessary risk because the understanding may have been incorrect or the logic/rule may simply change, what originates the need to rewrite the code.

MAKE IT WORK

By now the reader may have came to the conclusion that a evolutionary design projects may end up with no design at all, or a very poor design.

Critics accuse evolutionary design to be over-dependent on the maturity of the team, what is somewhat the true. On that matter, XP defines the role of a coach, who is a more experienced programmer responsible for guiding other developers in technical issues (including design).

Besides, there is a number of practices, from the agile environment or not, I believe should be judiciously used to maintain design quality:

• Emphasis on tests (unit tests, integration tests, etc): It gives you some confidence during design changes.
• Continuous Integration: keep the team synchronized with code and find out possible bugs earlier.
• Pair Program: If the functionality is complex, maybe a god idea to get two developers working on it.
• White box analysis: Its a good idea to keep an activity of code review to detect design issues that not necessarily show themselves as bugs.
• Good practices list: To keep a list of design good practices so the developers can refer to it when in doubt. The list could evolve as the project goes and experience is gain.

CONCLUSIONS

The agile wold has no place to up front design on its conceptual manner, as a well defined phase and trying to anticipate all details  of the development of a functionality, but it could benefit from some of it features such as better risk management and strong standardization.

Evolutionary design is an alternative approach indicated by the agile principles, but it must be applied together with other practices in order to keep the quality of the design.

REFERENCES

Great Martin Fowler article on design and XP (http://martinfowler.com/articles/designDead.html)

Article on up front design problems (http://architects.dzone.com/news/great-lies-design-vs)