Writing software is very much still viewed as implementation of a design. This is exemplified in the question asked in lectures: “Could you build a rabbit hutch?”. The building of the rabbit hutch is often the stage that needs the least thought; the design of the rabbit hutch and the consultation with the rabbits over what they want are much harder problems. It is the same with software. Fully specifying the solution (i.e. writing code) is highly complex but the actual building is a mostly solved and automated problem.
It is evident that the waterfall model draws some inspiration from the construction industry. The model is based around the concept that design changes after the completion of the build are costly if not impossible. The parallels drawn in this model are that the design is the stage of software development done away from the code such as requirement gathering. Actual coding (or what is considered to be the implementation phase) is analogous to the construction of the rabbit hutch. This comparison draws from the fact that the actual building of the software product (for a compiled language — converting it into a machine code) has become so cheap that it is almost free.
If we consider a design to be made up of only design documents and requirements then the majority of software designs are woefully underspecified with regards to their internal workings. They often fail to take into account edge cases and don’t fully specify the system, mostly due to a lack of understanding of the system. The acid test for this being to give the same design to two separate teams and getting different results as they both make different assumptions about underspecified areas of the design. A fully specified design would, in all likelihood, be executable and no different from what is considered in the waterfall model to be the implementation.
When an architect is designing a building the client is regularly consulted and shown mock-ups of designs varying from simple floor plans to physical models of the proposed building. Agile is in many ways a methodology that recognises this problem, with a work flow that is more in line with the idea of treating writing software as part of a design phase. The client is involved through the coding phase but rather than being shown mock-ups they are shown actual versions of the software. This cannot be done with physical buildings as the cost would be prohibitive.
Changing the assumption as to what the coding phase of a project actually is would fix a lot of the misconceptions made about software project management.
The central theme of The Mythical Man-Month is that adding programmers to a late project will just make it later. This may not seem obvious because if coding is treated as merely the implementation of a design then adding programmers should make the project progress faster, just as adding builders to a construction project can often make it faster.
To the layperson it makes sense that adding more architects won’t improve the rate at which a building is designed as they clearly associate what an architect does as a creative processes without a single solution. In changing the perception of programming to being equivalent to design the layperson’s perception of the process would also carry over to software. It would become more obvious that doubling the number of programmers wouldn’t halve development time.
The supposed high failure rates of products seems to becomes less of an issue when compared to other industries. Very rarely do you see stalled or unfinished construction projects. Harder to notice are the skyscrapers that never get built and the products that are never manufactured. In other words the failures happen in the design phase.
In designing a product, be that a rabbit hutch, a skyscraper or a piece of software. The designer is attempting to quantify the unknowns. So could I build a rabbit hutch? Yes. Could I build the Sheth Tower? Yes. Because if I have the design, a work force and the required money the majority of the unknowns have been dealt with, leaving me a far simpler problem. So the better question is “Could you design a rabbit hutch?”. The distinction is critical.