Why our rush to build software faster sacrifices quality and treats software like fast food

In August 2007, I was lucky enough to be able to edit an issue of Better Software Magazine. I was able to choose my authors: Alistair Cockburn, Jim Highsmith, and Jim Shore. I did this because I was lazy – I wanted great articles without a lot of effort. Choosing these authors guaranteed it.

In this issue, the Slow Software Technically Speaking column from the editor allowed me a page to rant about what was important to me – namely the tendency for software development to dig too quickly into building software before being clear about the context their software will be used in, the goals it should reach, and the problems it should solve. I tried to compare too fast software to fast food, and better software to slow food.

The short article described a conversation I had with a friend, the CEO of a company I spent many years working for. He described the propensity of his people to move fast – to get in, start capturing requirements, and start building software. In a lot of organizations that might be admirable. But for him this was often catastrophic. It resulted in the rapid development of the wrong software, and software that was less than desirable.

What was going on to him seemed like the rush away from building something of high quality to something fast and cheap. Like the difference between fast food, and something you’d pay more for from a fine restaurant.

It’s notable that when I say low quality that I’m not talking about bugs. I’m talking about subjective quality – the stuff that makes us like a product and feel good about our decision to buy it. See my short article on subjective quality on StickyMinds.com.

Immediately after the article was in print, I received a couple odd comments. One from a friend who said “I love this article, but I could never show it to my boss.” He went on to say that his boss would frown on any implication that things should take longer. I also received email from someone asking what the Agile community had to say about this. That’s why I’m writing this. If you’re reading this, you’re either in the Agile community, or listening in on what’s going on there. I’d love it if you could read the article, and give me some feedback.

I know I’m not alone in my sentiment. My friend Alistair recently sent me a link to this old blog entry from Frank Sommers discussing my coworkers Marc McNeill, Dan North, and Martin Fowler. Alistair said “other people are thinking like you.” In the blog entry titled Valuing Outcomes over Features Frank pulls together several conversations to talk about a possible 5th phrase in the Agile Manifesto. The point is that’s it’s a bad idea to focus on the scope we intend to build instead of solving problems, reaching goals, and generally delivering something people want and can use.

This is a “mom and apple pie” statement. No one wants to be responsible for building bad software. But, that said, I often don’t see people putting techniques into practice that stop it from happening.

For example, I teach paper prototyping and lightweight usability testing at a variety of conferences. (I’ll be teaching at OOPSLA and Better Software’s Agile Practices Conference if you can make it.) I know from personal practice that adding the techniqe into an Agile practice ultimately saves time and increases quality. Another friend, Gerard Meszaros, put paper prototyping and lightweight usability testing into practice on one of his projects. In a paper written by him and his customer for the Agile 2005 conference he describes what happened. Basically Gerard says that in addition to increasing customer participation and collaboration, the amount of rework they had on the project to change features went down significantly after the addition of the practice.

By “slow software” I don’t mean wasting time. I mean what’s meant by slow food. Focus on quality of delivery over speed of delivery. Hey, is that a 6th phrase for the Agile Manifesto?

What now?

Thanks for reading this blog/essay/rant! I’d love to hear from you, so please rate this entry, and consider leaving a comment. Or, send email to me directly.

If this blog entry was interesting, please take a look at all blog entries