A couple of weeks ago I was kindly given the opportunity to present at the Microsoft Architect Insight conference on the subject of Agile Architecture with my collegue Howard Van Roojen. We promised that we would post onto our blogs content from the presentation and any extra blogs covering topics we did not have time to cover. Up until now, this has not happened, as we have both been far too busy with projects going live. Well this week I plan to redress the balance by posting several articles on the topic, answering some of the questions we received, and documenting the presentation we gave.
This first post comes in response to feedback we received indirectly that Agile Architecture was basically RAD, because Agile processes use iterations and timeboxing which were first used in RAD. Whilst it is true that there are some similarities, there are also some key differentiators that make Agile projects very different in nature to RAD projects.
- Agile embraces the concept of contract first development required for either Object Orientated or Service Orientated architecture – RAD did not acknowledge the realities of designing to interfaces, partially because it preceded the widespread use of these techniques.
- Agile does not allow prototypes – RAD was based on designing prototypes and then reengineering them into production quality code (or not as was often the case).
- Agile projects logically break down the solution into features – the RAD approach did not do this; instead developers would focus on delivering all the features of the application by first doing it badly and then improving on the code base overtime..
- Agile teams are democratic. This means that the whole team has a say in the architecture of the solution, but the team is still lead by an architect. In contrast, RAD solutions were not based around the concept of a common architecture and thus individuals worked in silos.
- Agile development team members are self managing. In contrast, RAD teams are managed by a project manager. Note do not confuse the term management with leadership.
- Agile engineering practices (such as test driven development, and continuous integration) are stringent and thorough, ensuring that problems in the design or the code base are highlighted and fixed as quickly as possible, and that the team has the confidence to change the code base without breaking the product. None of these concepts were used in RAD projects.
- Agile teams focus on team communication and designing as a group. RAD teams tend to work as individuals, resulting in unmaintainable and poorly designed code.
- Agile teams only demonstrate completed work. RAD teams tend to demonstrate screen mockups, or prototypes, which lead the product owner to question why they now need to wait another six months for the completed product.
- Agile teams are based around disciplined individuals that remain continually focused on delivering real software. RAD teams lack discipline, simply because there was no structure to either the process, architecture or engineering practices.
- Agile teams are inclusive of testers and analysts and user experience specialists. RAD teams did not traditionally include non technical team members.
What is interesting about the comparison between RAD and Agile is that Agile projects are often labeled “cowboy developments”, because of the lack of heavy process. This is exactly the label that was given to RAD projects, because RAD had the key flaws described above. I feel those that label Agile projects this way are missing the point of Agile; the lightweight process coupled with the focus on production quality output works due to team interactions and group design sessions.