Bashing Agile / XP

I just read an article that takes a very cynical view on XP and Agile methodologies. I wasn't allowed to comment without signing up for something so I will comment here.

Check out the post "On the trail with the Cowboy Coders."

I think the author misses the point of Test Driven Development (TDD) and the XP practices, as a whole. His suggestion that XP is "Cowboy Coding" couldn't be further from the truth. In fact (this is always said) XP takes a great deal of discipline. All of the practices and values must work together or you will never reap the benefits of XP. In particular, TDD is not merely a way of making sure that your code is tested. This is a common misconception amongst those who have been newly introduced to TDD.

The reality is that TDD serves as a design tool. Now, XP does "shun" up-front formal design. But XP does not ask us to do "no design". The design is expressed differently....the design evolves. Let's take a look at how TDD helps our designs evolve. First, users write Acceptance Tests. Properly written acceptance tests are the XP team's first expression of a system's design. These tests are used as a road map for what the user should experience when interacting with the new system. Second, we have unit tests. Unit tests stress those portions of the system that are invisible to the end user. The scope of Unit Tests should be determined by the team...for instance, we tend to write a test fixture for each discreet component of a system. Finally, we write tests BEFORE we write code. Once we have a failing test we begin writing code until the test passes. It sounds strange, until you realize that the tests are more than tests...they are the design document for our new system.

Ask any XP team, it takes a lot of discipline. Most traditional teams save the tests until the end. They see the tests as something that would be "nice to have" but not really necessary. In general they just never get written. This coupled with another reality, that most upfront designs go out the door after a week or two, makes a pretty strong argument for using TDD as a design tool.

Now, before I conclude my little rant, I must remind everyone that XP/TDD does not happen in a vacuum. All the practices need to be applied. Remember "evolutionary design" happens as you go! Tests should be written when you need them not just because you want a bunch of tests. So please don't run out and write a ton of tests for crap you'll be working on next year. I guarantee that your requirements will change and you will have wasted a lot of time!

What is Important (Warning: Disconjointed Thoughts abound)

Well, It's been a while since my last post...trust me I've been busy!

I've been reading quite a bit about Agile Developmet trends. Always ready to learn some new nugget of goodness. I always find myself asking, "What is really, really important to an agile project?" Is it simplicity? Test Driven Development? Pair Programming? Evolutionary Design? One of so many other values and practices?

Of course my first response is, "it's all important, XP requires a tempered application of ALL the values and practices."

We have so many around us that don't like this answer. They wonder, "where are the controls? What is the process?" My answer is, inevitably, "the team is the control and the process. They are guided by a coach and a good faith effort to provide regular software releases."

I must admit that, in business, we need to"know". Know when the software is going to be done. Know when the software is not going to be done. Here, I argue that most methodologies fail to effectively predict these things. So, why not select the methodology that wastes less time on fruitless planning and more time on fruitful development?


I am a huge fan of pair programming. Actually I am a huge fan of many of the more painful practices;TDD, Integrate Often, Simplest Thing That Could Possibly Work, etc. I think they force us to do the right thing. I've also found that most of the practices hinge on pairing. Navigators always seem to be sticklers for doing the right thing.

As usual my thoughts always return to simplicity. I like to think of simplicity as the "golden value". It's importance can never be overstated. Everything that goes wrong in software development can somehow be traced back to some complexity. Simplicity makes the code easier to write. Simple requirements require less time to design. Simple designs require less time to implement. Simple code is easier to integrate and maintain. Easier means faster and faster means a quicker and greater return on investment.

So what makes something simple? Is it simpler to just drop a datagrid on a webform or to use MonoRail views and Brail? What about IoC containers? Is dependency injection complex or simple? I bring up these points for a reason. I read a blog with a pretty half-hearted flame about these same things. I must tell you that I am easily side-tracked by these sorts of discussions. I want things to be simple! Shouldn't WebForms controls be simpler? Or why go through the through the trouble of implementing an IoC container? I'll try to answer....

I could just say, "these are the patterns we choose to use and it makes the code simpler to maintain and refactor (remember refactor mercilessly)." This works academically, but the real truth is that it "feels" better. The WebForms designer still has a cludgie feel to it. The code it generates is nasty. Also, the MVC framework takes away 90% of the design decisions and, as a framework, is simpler to wrap your mind around. The IoC containers simplify the bulk of the coding...the IoC container is complex...but it's done already! Finally, Dependency Injection really supports "once and only once" and allows you to design objects that do or express ONLY what they are meant to...that's simplicity.

My next post I hope to expand on some of the "big words" and ideas above. Please comment on what you believe is most important!