Despite the fact that iterative approaches to software development are increasingly used, most of the people paying for IT software developmet have an expectation that we should be able to tell them—before coding starts—"what's it going to do, what's it going to cost, and when's it going to be ready?" This article exlains why that's an unattainable expectation and corrects the misleading "product-lifecycle-model" for estimating.
Fixing the misunderstandings about estimating iterative projects requires a look at a language issue. At least part of the problem can be traced to the words and models we use to explain our work. First, we typically present the software-development-lifecycle model without putting it in the context of the software product lifecycle. Second, when we talk about the development lifecycle, we use words that lead the listener to compare what we're describing to other product lifecycle models, not other development lifecycle models. Worse yet, we use language that causes users to compare our development lifecycle model to the wrong industry.
To clarify the misunderstanding, we need to place the development lifecycle into the context of the product lifecycle. Why? Because any misunderstanding at this level virtually guarantees false expectations. Product lifecycles are inherently sequential. To use a manufacturing analogy, when PCs come off the assembly line they're supposed to go to customers, not back to engineering. Development lifecycles, on the other hand, are inherently iterative. The engineering groups in a PC manufacturer typically produce several iterations of a product before the design is called final and released to the manufacturing
Iterations in a development lifecycle represent learning. Iterations in a product lifecycle represent waste. We need to make sure that our customers understand the difference between product lifecycle models and development lifecycle models and, when it comes to expectations about predictability, that they are using the appropriate concept. Why would business people think we're talking about a product lifecycle rather than a development lifecycle? In presenting the SDLC we use words that almost automatically lead the listener into that trap. Have you seen SWEBOK? The IEEE recently released the trial version of the Software Engineering Body of Knowledge. You can download it at www.swebok.org.
What does it call the coding phase? Construction. The presentation of the SDLC as "Requirements Design-> Construction-> Test->" corresponds all too closely to the product lifecycle for the building industry. Google "building lifecycle" and you'll find a paper on "Sustainable Design" by the University of Minnesota College of Architecture and Landscape Architecture, which characterizes the building lifecycle phases as Pre-design; Design; Construction; Occupancy.
Both the model and the words we use to present the SDLC make it easy for business people to make the mistake of comparing it to a product lifecycle model. What happens when they do? They expect coding to be like laying bricks. They think, "All we need to do is estimate the number of bricks (or lines of code) we'll need and, voila, out will pop a reliable estimate!" Flawed analogies lead to flawed expectations.
As if it's not damaging enough to make inappropriate comparisons between the wrong models, the use of the word construction in the SDLC leads the listener to compare the wrong industries. The examples from the building industry that come to mind for a typical businessperson are much too simple. The manufacturing industry, especially PC manufacturers, provides much more appropriate analogies. Both computer hardware and software are logic-based. They're obviously related since software runs on hardware. And when you compare the design phases of the product lifecycles, you get very good analogies.