2009-02-17
Design versus construction
Every so often, people compare programming to something like building a house and ask why software projects can't be half as well estimated as physical engineering projects typically are. One of the many reasons that this is a bad comparison is that physical engineering is different from software engineering in a crucial respect.
The process of getting something physical constructed is generally divided into two phases: design, the intellectual engineering work, and construction, which is theoretically mere unintelligent physical labour. Thus, once you've finished the design work, the construction time can theoretically be predicted fairly well, since people have a fair amount of experience with how fast various sorts of construction go.
And generally we only talk about the construction time. The design time is implicitly swept under the carpet, partly because the construction times are usually much longer and more expensive than the design times (especially for difficult engineering projects).
Programming is not like this at all. To the extent that programming even has 'construction', things that can be done without needing to make choices and explore options, these things usually have already been automated. There is a whole infrastructure of compilers, libraries, high level languages, and frameworks that are in themselves the 'construction' (and are often done with far more sophisticated techniques than would be feasible for physical construction). This leaves programming with only the design phase; thus, there is no real 'construction time' to be estimated for a programming project.
(All of the sophisticated time estimation methods that we've evolved for software projects are best understood as attempts to predict and monitor the uncertain process of design, to guess how long it will take and to notice when things turn out to be more difficult than guessed.)