As I was saying yesterday, most customers can not fully and vividly grasp the complexity of the software required to deliver even a rudimentary solution to their problems. Most customers understand this by now, and are willing to accommodate whatever path we recommend towards solving their problem. They don’t care too much whether we prefer traditional or agile methods. Proponents of agile methods tend to suggest that at least with their method, customers with the same money and the same initial vision wind up with their needs met most closely than with traditional methods, and I agree that seems more likely to be true.
On the other hand, in the real world, most customers need to be able to justify large expenses before they commit the money, not after. And no matter whether we start with agile or traditional methods, they won’t have a clear idea of the actual outcome by the time they need to make the decision whether to spend the money.
On an agile project, we could ask the customer to commit to only small steps at a time. For what will ultimately be a $100,000 piece of software, we ask for commitment to only $10,000 at a time. We’ll deliver exactly what we said we would with the first the $10,000, and the second $10,000. The customer will develop faith in our ability to produce what they want, and we repeat until we’re done, eight iterations later.
But before that customer agreed to pay the first $10,000, we will have had to explain that $10,000 wouldn’t really meet their needs, and that several more iterations would be needed. How many? We don’t really know. We guess, and we point out that it’s more likely to cost less and work better than traditional methods. How much? The customer really needs to know whether they are embarking on a $25,000 project or a $400,000 project.
Steve McConnell is an expert that every software developer should get to know. As he writes in his book, Software Estimation: Demystifying the Black Art (Best Practices (Microsoft)), “Many businesses value predictability more than development time, cost, or flexibility. Be sure you understand what your business values the most.”
Most businesses—for that matter, most people—want to know before they agree to commit any money to a project at all that they will get the value from the project that they need to get in order to make it worth the money. An agile process can’t guarantee that outcome from the beginning with any more certainty than a traditional process. It simply promises to deliver successive versions of something that the customer agrees is more valuable than previous versions.
I’ve compared building software to building actual buildings, but there’s a great big discrepancy in that metaphor. It’s this discrepancy that agile methods attempt to address, and it’s because of this discrepancy that no actual buildings are ever built using agile processes. Creating a building involves the aggregation of a number of tasks, each of which have already been done many times before by a wide variety of people. It’s well known how long it takes to get permits, draw up blueprints, hire subcontractors, prepare the land, lay the foundation, erect the frame, cover the roof, install wiring, ductwork, and plumbing, put in sheetrock, tiles, and ceiling panels, lighting, windows, lay carpet, and paint. Those tasks have to be done for virtually every building ever made. The tools used for one building are the same tools for all buildings. And nearly every part of the building is something that the customer can tangibly grasp.
In contrast, building software is frequently filled with tasks which the developers have, at best, only read about. A new development technology is not like an improvement on a screwdriver; better, but you still use it the same way when turning screws. It’s more like switching from a screwdriver to a rivet gun. And then from a rivet gun to a laser welder. And more often than not, we have to find a way to use the laser welder when an ordinary screwdriver might have worked better.
To complicate it, the relationships between components in software are not as obvious or well understood as the relationships between components in a building. That has to be worked out each and every time with each software project. And finally, most of what makes a software project complete is never directly seen or controlled by the customer.
If we reverse these comparisons—that is, if we had not been making building for thousands of years, but had been building software the way we do for that long, and were now trying to apply software development concepts into building construction—then buyers of houses and buildings would face a pretty crazy process. The customer would come to you and say they wanted a building that they could put their family and their stuff in, and they wanted to know how much it would cost.
The Traditional Process applied to People Containers
Customer: “I’m getting married in three months, and I need you to put together a container where I can protect my wife and myself from the wolves and mountain lions. But first, I’ll have to get money from my dad, so I need to know how much this will cost.”
Traditional Developer: “A container in three months? I need to know a few things first. How much time each day will you and your wife need to spend in the container? And how long does the container have to last?”
Customer: “Well, mostly we need it at night when we’re asleep and can’t be on guard for predators. How long? I don’t know. I guess a couple of years, when I will have money of my own and can get a better one built.”
Traditional Developer: “There a lot of options, and the costs range widely. For example, I could make a couple of small wooden boxes with padded lining for you to sleep in. They’re only about $2,500 a pop. Less if you use cheap wood, like pine, which you might be able to do since you only need it for 2 years. But some people get creeped out with those, because they’re basically the same thing they’ve been using when they put dead people in the ground. Or, we could go to the high end, and put together a large ball made out of cast iron with a watertight door, put in an airhose and a pneumatic pump, a mechanism that can raise and lower it every night into the lake. But that’s kinda pricey; it could cost about $1,500,000. I think that’s what Bill Gates uses. Maybe I’m thinking of Larry Ellison.”
Customer: “I can’t spend that much, but my wife will hate the wooden boxes. What can I get for about $10,000?”
Traditional Developer: “I think we can build you a platform that has been suspended from a large tree, and we’ll put a bunch of iron bars around the sides and top to keep out the mountain lions that might try to jump from the tree. You’ll have a rope ladder you can pull up when you don’t need it. Although, you should know that we’re trying a new thing with the iron bars. We’d been just tying them together with rope, but the rope tended to fray in a few months and the bars would come loose. So we’re planning to use a new technology to keep them together. I think it’s called “wedding.” No, it’s “welding.” They’re using it in those other projects – the ones that connect roads on both sides of a river. Bridges. We haven’t tried it with people containers yet, but I’m sure it will work great here.”
Customer: “And I can get that in three months for $10,000?”
Traditional Developer: “Um… yeah, that sounds do-able. Obviously, I’ll need to get more requirements from you before we really commit to the schedule.”
Customer: “That’s fine, I just needed to know how much I needed to ask from my Dad. I’ll call you back when I have the money.”
Out of time for today. I’ll be back tomorrow with the same conversation, only this time with the Agile People Container Developer.