There have been a number of people over time that have taken issue with the analogy comparing software development projects and real-life construction projects. Many of these tend to point out the many differences between what software is and what buildings are.

However, taking a different approach, Alistair Cockburn decided to see if he could use agile methods in coordinating his house renovations. He’s very happy with the results for a number of unexpected reasons and he did an interview with Agile Advice describing why.

This full Java call stack between the HTTP and DB layer gives a visual representation of the problem with most “Enterprise” Java Web Applications today. And the problem really isn’t the number of layers (this one shows 97); most of them are optimized and hidden from the developer anyway. The problem really lays in the ratio of blue (plumbing) to yellow (business logic) boxes (10:1). The goal of any modern software framework should be to minimize the amount of plumbing, freeing the developer to spend more time on business logic which directly converts to business value.

Jason Fried recaps a couple of chapters of his excellent Getting Real book in a short presentation at the Collaborative Technologies Conference. Here are the slides (PDF) so you can follow along. Jason gives a little background on the presentation over at Signal vs. Noise.

If you have seen Jason speak recently or read Getting Real this will likely be a review but I can really appreciate Jason’s message and the manner in which he delivers it. A 15 second recap might look like this: Keep teams small and apart from one another, minimize meetings and make many small decisions as opposed to fewer larger ones.

Martin Fowler speaking at Rails Conf 2006, describes the Web 2.0 software development process as a process that works in the reverse of traditional software development processes.

There is this culture of just give the product to the customer. Then see how they use it. Ship the product, then gather the requirements. The opposite of the traditional process. Fire, aim, fire, aim. As long as the bullets are cheap.

He continues that short cycle times and cheap bullets are hindered by traditional software “Plumbing.” The Web 2.0 development model gets the plumbing out of the picture so the conversation between the customer and the developer is not muddied. This decreases cycle time, effectively increasing the chance the end product will actually be what the customer needs.

Thinking about all the “enterprise” Java web applications I have written in the past, I get the sense that he is dead on. Generally 80% of my time is spent building the plumbing; (build scripts, sql scripts, beans, actions, jsps, and the bazillion of object transformers across all layers) and less than 20% is actually business logic; (flow control, business rules, validators, dynamic UI, etc). I find I am most productive after a project has been around for about eight months and all the patterns and plumbing are in place. At that point adding new features is usually a job of copying a bit of plumbing and adding the 20% new logic. The problem is that eight months in world of software is an eternity. By wasting your time on plumbing, your application is becoming out-dated and the technology stale. I guess that is some of the allure of “Spring” and other packages that claim to cut down the plumbing. I believe you will only really begin to see time savings by moving to a model of “convention over configuration” and getting rid of the configuration bloat, something Rails gives you out of the box.

Ok, we are to a point where we want to get the posts flowing here on the spiffy new refactr site. There are still a lot of things left to add (like everything besides this blog) but that will have to come online while we post. The blog aspect is the main part of this thing anyway as it starts the discussion that we would like to have. Namely, the discussion centers on the agile method and our experiences using it to develop web-based software.

Who are we? Of course, some introductions are in order. I am Ben Edwards, I am a designer. I try to take on the role of the user in our software development and try to design the applications and sites for me. I have maintained a website since 1995 and blogged at AltText.com since early 1998. Then there is Jesse O’Neill-Oine, Scott Vlaminck, and Casey Helbling. I work with them and I will let them make their own introductions as they start posting.