Agile development is taking over software development practice, step-by-step, it seems. And generally, that is a good thing, as it is a collection of best practices that can improve the way software is developed in many organizations. I do believe many of those are here to stay.
However, as any new hot topic ('hype', if you prefer), it takes time and patience for people to pick up the true meaning, and in the process, a lot of simplifications are made, a lot of nuances ignored in the process of explaining and emphasizing all the 'new' and different things. For instance, a lot of people believe agile development equals the use of an incremental project management like SCRUM.
As another example: the Agile manifesto (http://agilemanifesto.org), says that it puts the emphasis on, for example, "Responding to change over following a plan", and that one of the principles is "Simplicity--the art of maximizing the amount of work not done--is essential.". A key role in achieving a decent architecture design is played by continuous refactoring, whereas Test-Driven Development ensures that the code does actually work correctly, at least according to the test specifications. Now these ideas are emphasized so often, that some get the impression that this means that one should not plan ahead, make no architecture or design ahead at all, everything will just emerge by developing code (and evil tongues suggest that they also prefer it this way--in fact they always started coding immediately on each project, long before the Agile Manifesto).
However, there are some serious risks with this misconception:
- First and foremost, it is crucial that a system is developed around a clear concept of the core solution, and the structures that are needed to support it. Such concepts come domain knowledge; both from the application domain as well as the solution domain. This is essential to build systems that work well with respect to their users. A quote from agile founding father Kent Beck explains this well: "you can't hide a bad architecture with a good GUI.".
- Secondly, without a good understanding and supporting structure of the underlying concepts, many of the changes that will -indeed- come, can only be realised by rather ugly hacks (which we will of course never do) or otherwise by restructuring; i.e. literally reorganizing the structure of our system.
The implications of restructuring can be manyfold:
- Responsibilities shift and are refined, often distributed over multiple locations, sometimes merged.
- As a result, methods or parts of methods must move, methods are split, part of methods are combined. Refactoring tools can help a great deal for each such individual action, but managing large amounts of such changes without a good plan (e.g. before and after design models), is very hard to do right. It is also hard to do this in small steps that can be immediately tested, as there may be many dependencies that must be 'fullfilled' first.
- the behavior of methods must be refined (=modified), split, or merged; this also requires adapting all corresponding tests; it will often happen that such changes cascade through in the behavior -and hence tests- of other methods; not a simple and desirable situation. Fortunately -but in a way proving my point-, there is a good back by Gerard Meszaros ("xUnit test patterns--refactoring test code") that is largely devoted to ways to handle this problem.
For now, let me just finish by stating that scalable agile development requires a decent balance between upfront (architectural) design, continuous monitoring and refactoring of that design, while keeping a focus on working software, with working tests. As implied by the title of this post, I will surely return to this topic. |
