If there is anything inherently true about software development, it’s that it’s difficult. Or as some have said, wicked. As developers we need to realize we are solving “wicked problems” — problems with unstable problem statements, uncertain finsih criteria, no single objectively “right” solution, problems not exactly like any others that have been done before, few or no easy ways to experiment with possible answers, or many possible solutions to choose from. Often, all of the above.
Awhile back, I posted what would eventually prove to be the most popular post to date on this blog: “Software — Cheap!”. Superficially, it was a riff about freelance software project web sites that marry wildly ambitious but super-sketchy requirements with budgets so microscopic that you would be hard-pressed to get a leaky faucet fixed for the same money. This led me to remark about how, in the minds of some, software development is nothing more than a low-skill, mechanical exercise, like assembling Lego blocks.
The antidote to such thinking, I said, is to stop running from the reality that software development is inherently difficult — especially in the matter of project scoping and estimation. I even went so far as to suggest that in many instances there is no way to know how much time and effort a project is going to take, until you’re basically done with it. Now if that’s not wicked, what is?
A commenter to that post asked, “I don’t understand why you think that software cost can’t be measured or foreseen. I work for a consultancy firm. We do it all the time and it works.”
For the record, I give estimates, since customers understandably want them, and I do have a reasonable idea how much is involved in a project based on my understanding of the requirements at any given time. The problem is not the impossibility of measurement or foresight; it is the non-static nature of what you’re measuring.
By now, the so-called waterfall methodology where you do requirements gathering, development and testing in a linear sequence, has been pretty much discredited by anyone with eyes to see and ears to hear (here’s a good example). There is plenty of room for disagreement about the details, but it’s now widely acknowledged that a more iterative process is needed. Iterative approaches are non-intuitive for customers who don’t understand the differences between software development, and, say, house painting. But iterative approaches are more successful at producing quality software.
Fred Brooks in his seminal work, The Mythical Man-Month
Developers can (and do) ignore this principle, but as Brooks implacably states, they end up throwing one away anyhow. It might be swept under the carpet and not admitted to, but it gets done.
All of this is not to say that we can’t estimate, or that we shouldn’t do discovery or planning. But it is to acknowledge the substantial limitations on how accurately we can estimate, how completely we can discover all the requirements, how on-target our planning can be.
One big factor that limits the effectiveness of discovery is that in all non-trivial projects, discovery is a complex social interaction involving multiple stakeholders. It is as much a social and political exercise as a technical one. And generally, the signal-to-noise ratio sucks. Also, the desire of customers to actively and meaningfully participate often is very low; customers commonly do not expect to have any great level of involvement in the process. Thanks to the business world’s strong bias for action over thought, they just want to wave their hand, make a one-sentence request, and have you go away and Make It Happen. This only makes matters worse.
A few years back I worked with a client who had conceived the idea for a business-to-business web site. He had already “thrown one away” by paying an undergraduate at the local university to develop the product as a CD-ROM-based distribution, which was a total flop. I was able to take that fundamentally sound idea and translate it to the web. The site made my client a lot of money. He sold out to an east coast competitor, and went into much-deserved retirement.
Was my predecessor who did the first version an incompetent fool? No, he was an important part of the discovery and design process, even though we ended up changing a great deal the second time around. A year was spent on that “thrown away” design, and I’m sure my client hoped, naively, that he could start making money at the end of that year. But he was smart enough to realize that he needed to leverage that learning experience. He also believed enough in his concept to see it through.
Now my client, bored with retirement and free of his non-competes, is itching to reproduce his success with a slightly different twist. I get calls from him every few days, asking me how long I think it will take, what I think the best approach would be, how should he present the idea to this or that prospect. And you know what? I have a general idea, but I just don’t know exactly because I don’t have enough data. The client doesn’t, either. This might be version 3.0 of a great idea or version 1.0 of something that morphs out of that original idea. But my client is paying me for my time and we’ll work it all out together. And about the time we have a real grip on it … the project will be at least half done, I’m sure.
| Recommended Further Reading | |
