Last week I had a fascinating conversation with Jeff Patton. It began with me telling Jeff that I think there’s a rift between the people who know Agile (the folks who have been doing it for the last 10 years), and the people who can actually be agile (Rubyists, for example). Agile consultants spend their time trying to get shops to do TDD & iterative development, which are taken for granted at a lot of Ruby shops (though the quality and extent to which this is done may be up for debate). I think it would be interesting, to an Agile expert like Jeff, to work with a team that doesn’t have the same sort of organizational friction to adopting Agile practices that he may be used to.
Jeff’s reply shocked me:
“The Ruby community cares about building high-quality apps, but doesn’t necessarily care about shipping high-value apps.”
Jeff went on to say that the Ruby community is obsessive about craftsmanship. This is a good thing, of course. We test. We write clean code. We take the time and care to build applications that are beautiful and do what our customers ask for.
Therein lies the rub: what customers ask for is rarely what they want, and almost never what they need. As Henry Ford put it, “If I had asked what people wanted, they would have said faster horses.” Or as I put it, your customer may pay you $1000 to deliver him a knuckle sandwich, but no amount of precision or strength training is going to leave you with a happy customer.
It turns out that constructing a high-quality application is not enough – you have to conceptualize and design an application that users will actually find useful. Doing this is every bit as difficult as constructing the software, if not harder. It requires a combination of research – generating new ideas from asking questions & identifying problems – and feedback – testing out ideas you’ve created. The Ruby & Agile worlds have been primarily focused on getting user feedback, without doing the all-important research.
Perhaps the most interesting thing he said was that there’s an important shift in responsibility that needs to take place. The people who know software need to take more responsibility for the success of software projects, and that means being more active in the research, conceptualization, and design of products. He said that there are a number of well-known “elite” development firms out there that will gladly cash your company’s $250k check and build an app that they know is not likely to make any money. It’s easy to point to the numbers in order to shirk responsibility – 90% of businesses fail within a year of opening, and 90% of the ones that do make it past the first year fail within the next five. The numbers are pretty consistent with Jeff’s experiences. He claims that fewer than 10% of products built by consultant shops reach a point where they actually make money from the product.
He told me a story of a project he worked on a while back with some really smart people, and the project was regarded, by the programmers at least, as an “Agile success story.” The team did all the practices, delivered software regularly, and had low defect rates. The only problem? Customers hated the software, and the business went extinct.
I’m not 100% sure what to make of his comments yet. I’m proud to be a part of a community that places such high importance on craftsmanship. But it seems clear to me that there’s a piece missing from our discussions. Maybe we’re doing the software equivalent of bicep curls, and effectively punching our end users in the face. Just something to think about.