The thing I like about the Agile process is that it realizes this and tries to minimize the concept of a "release date" or "now it’s finished". Customers should embrace this as well, because they can stop spending money at almost any time and get a finished process.
And that got me thinking. We all know the story. A company needs a custom application done. They find a good consultant. Preferrably a Delphi consultant. After all, why would they choose any other tool? But of course, then the dreaded question comes: “How much will this cost and how long will it take?” No one wants to answer that one.
Developers, academics, business people, and probably a variety of wizards, kooks, and psychics have tried to solve this eternal problem. In my view, though, it isn’t an answerable question. I don’t think it is really possible to predict how much time (and thus how much money) a software project of any significance will take. Oh, sure, you can estimate, but of course your estimate is wrong. It will always be wrong. It seems to me that there simply are too many variables and too many unknowns for anyone to be able to predict with any accuracy the cost and scope of a given software project. Anything we do say is just pretty much a guess.
And we all know how it ends. The project invariably ends up costing more time and money than predicted, the feature set gets cut, the project gets shelved, or something not quite useful gets deployed. It doesn’t always happen that way. Clearly successful projects get deployed, but we’ve all heard statistics that outline the harrowing percentage of projects that fail. However, I think most of us would agree that estimating a software project is black magic at best.
(An aside: what I’ll be discussing below is custom business software, not shrink-wrapped software. Shrink-wrapped software is another beast altogether, and (surprise!) I have some thoughts on that as well).
As I said, I’ve been thinking on this. I think part of the problem is the “manufacturing” mentality of software development. Business is tuned into the idea of building and manufacturing things. They build cars and houses and bridges and iPods, so naturally, they want to build software. So, what do you do? You draw up some plans and you build it. You decide ahead of time exactly what you are going to build and you build it. Manufacturing processes are pretty well known, so you know what it is going to take to build this thing your want.
But software isn’t a bridge or an MP3 player or a television. It’s much more complicated than that. Now, a TV is pretty complicated, but its algorithmic. We know what it takes to build a TV. Once they are designed, they can be mass produced, and they actually have surprisingly little functionality for the end user. A software project is much different. It will probably have a large amount of functionality, but it will be unique to each customer. The process of actually manufacturing it can’t be predicted as it can with a car or a refrigerator.
So a customer wants a software solution, and so the approach is to look at it in one big chunk, as one thing to be done. But is that the best way for software to be built? I think we’d all agree that the “Specify it out, estimate the cost, go off and build it, uh-oh it will be late and over-budget” way of doing things isn’t working as well as we’d like. Maybe there is another way to look at things?
How about we think about doing it this way: When the customer says they want a specific software project done, they might try this: Start with a collection of basic, minimum requirements, build those, and then go from there, wherever things may lead. Incrementally add functionality, one feature at a time. Don’t even think about the next feature until the current feature is implemented and working. Deploy the application after each feature is completed, and let the “go with the flow” mentality determine what the next feature will be. (I suppose you can have a little list of features going, but think only in terms of incremental improvements and updates.)
Doing this will allow the customer to control the project much better. They can stop the project at almost any time and have a functioning system. They can specify features to match rapidly changing business needs. Things that they want today and would otherwise have written into a specification are things that they might not need at all in six months. The customer has a fixed budget? Then he gets a certain feature set commensurate with his needs and his budget. That feature set will be the most needed and important features. There may be other features the customer wants, and when more money is made available, the application is ready to have them implemented.
Now, I am fully aware that what I’ve just described is pretty much what Extreme Programming is. However, the thoughts that were running through my mind were about how to present this to a potential client. On the face of it, this all sounds crazy. Customers might be uncomfortable with the idea of not knowing precisely what is going to happen. But it seems to me that customers are going to be uncomfortable no matter what. In the old way, they were a bit uncomfortable at the beginning of the project and really uncomfortable at the end. This way, they are uncomfortable a bit at the beginning, but their comfort level rises as the project goes on as they see it improving and moving in precisely the direction they want and under a budget that is much more manageable. Its a win/win situation all around.
I could go on, but you all have probably read up on XP and what not. I guess my main thought here is that in order to serve customers better only if we can somehow convince them of the wisdom of a new approach.
How do we sell it?