Reasons Why Linearity Doesn't Work for IS-department-type Software Development
Software project content is much more capricious. In construction work the content, once established, is relatively straight forward and less likely to change in any major way such as the height of a building or length of a road. Relatively small changes can be handled by well-established change procedures. For most construction, especially fixed-price contract work, the amount of work involved is clearly understood. Software differs for several reasons.
- Software is interactive and has a lot of "behavior", i.e. functionality, which makes it harder to specify. For exactly this reason, users, the ultimate customers, find it difficult if not impossible to specify their exact requirements at the outset. "Give me something to look at and I'll tell you if I like it" they cry!
- Consequently, it is not possible to establish cast-iron specifications covering subsequent execution work.
Scope is a more active variable. In the traditional construction tetrad tradeoff of scope-quality-time-cost, scope is usually relatively fixed. You would not, for example, contemplate building half a bridge in order to provide twice the number of lanes over that half. It just would not make sense. In software such a compromise is more likely, and plausible, especially if unexpected risks are encountered.
It is almost impossible to "freeze" software specifications. Linearity depends on freezing work done before moving on to the next phase, but in reality nothing stays really frozen. As we've seen, the customer is rarely able to completely specify requirements sufficient for development. Similarly, the designers are unable to tell whether the various technologies to be used in the final solution will in fact work together. The complexity of software development, and the pace of change of software tools, makes it almost certain that there will need to be fixes for flaws in assembly.
Besides, when the users get their hands on the software, they will inevitably discover better ways to use it or have it work better. User interaction with the software is a very personal thing. A successful interface may well depend on what other software is familiar to the user. If it doesn't work the way expected, i.e. it is "counter intuitive", changes will be necessary such that users finally "own" the result and call it "user-friendly".
Some scope creep is inevitable. According to Hal Helms: "Scope creep is the pejorative name we give to the natural process by which clients discover what they really want. This puts our attempts at "requirements gathering" in a different light. Most project managers try their best to discover what clients want at the beginning of the project. They use meetings, questionnaires, personal interviews „ and still, the most common experience for developers delivering a final product is customer dissatisfaction. It may come as a slap in the face: "This is no good"; or it may be couched in gentler terms: "You know what would be nice?" but the same message is being delivered „ we aren't giving clients what they want."[1]
Building software is all intellectual work. The results are "abstract" in the sense that the real value of the product is in its performance not in its tangible evidence, i.e. the hardware it sits on. It is the result of brain work, not brawn work, the outturn of a different kind of worker who needs to be managed differently. At the same time, it is more difficult to establish how many lines of code will be required to achieve the required functionality, given all the possible permutations and combinations. Consequently, it is more difficult to assess interim progress or, indeed, when the final product is actually complete.
Software scheduling logic is not self-evident. In construction, you cannot put the roof on until you have built the walls. Software development is more like road building — you can start anywhere you like, but smart contractors start with building the bridges, the most difficult and possibly risky parts, but in a logic sequence that is not linear.
You cannot schedule software projects by effort calculations. You might be able to halve the time for constructing a brick building by doubling the number of brick layers, each working their own section until they meet at the junctions. However, you cannot do the same with software because of the interaction necessary. As you increase the number of programmers on the same element, the number of interactions increases exponentially until interactions exceed the rate of progress and the work collapses. To quote an old saying: "You cannot reduce a pregnancy to one month by impregnating nine women."
The exposing of risk tends to be different. In construction, the biggest risks tend to be associated with site conditions which can be dealt with early on. Subsequent risks having to do with workmanship are mostly visible as the work progresses. True, "latent" risks, discovered after completion, are a possibility but tend to be relatively rare. In the case of software development, risk sources, e.g. unanticipated interactions that don't work, are more likely not revealed until later. That is, when the whole system has been in use for some time and users become sufficiently familiar to push the application to its limits.
1. Hal Helms, http://www.alistapart.com/stories/scopecreep/
Issue #150, September, 2002
|
Rapid Prototyping
