alacrity in action
| Tags: , , ,

Agile teams are neglecting design.

I can already hear your objections. Surely, you will say, many Agile teams these days do test-driven development and TDD is all about design. I absolutely agree, after all, I dare not question Uncle Bob who, in his “Agile Principles, Patterns, and Practices in C#” book clearly says

“The act of writing a unit test is more an act of design than of verification”.

The problem, however, is not if we are doing TDD but how we are doing it. Writing unit tests before production code, watching the tests fail, writing corresponding production code until the test passes and then refactoring requires discipline. Many new Agile teams lack that discipline. To gain the full benefits of TDD also requires a lot of practice and teams may simply have not had the time to accrue enough.

These two obstacles aside, I still don’t see the practice of TDD shaping the design of teams’ code in a way that Steve and Nat describe in their excellent “Growing Object-Oriented Software, Guided by Tests” book. I think among the reasons sits this one: frameworks.

I see this time and time again: a new engaged, eager and energised Agile team sits together to start a new project. They want to break away from the old ways of working. They have already been freed from the heavyweight processes which required lengthy documents, endless approvals and then subjected them to a stream of bugs arriving weeks or months after they last touched the affected code. They also take this as an opportunity to break away from the technical baggage accumulated over the years. Not doing so would be to neglect the Conway’s law.

And then what does a team do? They pick a framework. Chances are, if you are an Agile team writing a website in .Net you will go for the ASP.NET MVC framework. If you are trying to move away from the monstrosities of Java Enterprise frameworks or got tired of Spring you might be moving to grails. If you are more daring you drop you old technology altogether and pick rails. Add an ORM on top or something from the NoSQL pallet and your fresh new architecture is ready waiting for you.

While there is absolutely nothing wrong with these frameworks and technologies, making such choice means you have given up design decisions that you would have otherwise had to think about. You start working within a framework and then your thinking re-focuses to consider how best to fit your problem into the skeleton which is already in place. It might be slightly awkward to write some of the unit tests but you just blame that on your inexperience with the new technique.

Isn’t it ironic, that as we free ourselves from the rigidity of the organisational processes we are willing to subject ourselves to the rigidity of the framework structures.

In the short time, we go astonishingly quickly, new functionality flows into releases, new pages appear, database expands magically and there is none of that old hand-crafted SQL to worry about. Many Agile teams are probably still at this stage. The will go on to neglect design, they won’t question the structure of their code at various levels, they won’t reevaluate their architecture. Then strangely, release by release, they start to slow down. Features become more difficult to implement, changes solidify, codebase stagnates. 

I just hope it’s not your team.


Comments5

  1. Absolutely. It is exactly what I am seeing at the moment, but in this case they don’t do TDD because it might politically conflict with what the “QS” people do (especially the BDD/ATDD variants of TDD), and the design is already there in the form of a home made framework, trying to use TDD AND the framework is so much slower than copy-paste that it isn’t worth it.

    Hmm doesn’t sound very agile at all does it?

  2. Pingback: In the News: 2012-03-28 | Klaus' Korner

  3. You raise a good issue. Frameworks are starting points not final system designs. They are tools not solutions.

    The underlying development approach is not the problem. Any team can fall into the trap of blindly using a framework in order to meet a deadline or minimize an element of risk. Good teams owe it to themselves and their stakeholders to build the best systems they can within the constraints being imposed on them. Great systems are build on great designs. Great designs evolve as the system is built out. That’s agile!

  4. I prefer using libraries over frameworks, because I can remove duplication in the direction of libraries, but frameworks limit where I start. Even so, I can imagine one context in which I disagree with “While there is absolutely nothing wrong with these frameworks and technologies, making such choice means you have given up design decisions that you would have otherwise had to think about.” Namely, I have written an Enterprise Java application from the ground up with no frameworks, in an attempt to discover which properties of a Web/MVC Java framework make designing with tests easier and which properties make that more difficult. Once I did that, I felt like I could reasonably comfortably choose a Web/MVC framework for Java that fits how I think about building these applications.

    In the Ruby world, I like Rails, but I sometimes think that I’d like to repeat my Java experience in Ruby, so that I understand better what I appreciate in a Web/MVC framework and what I don’t.

    • Thanks for your comment J.B.

      I absolutely agree that choosing a framework (especially something like an MVC framework) can be helpful and beneficial, I can only wish that every team was as diligent as you describe in making the choice. I don’t think you get the benefits unless you go trough such process, at least in your head.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.