Comparative Analysis of Software Development Metaphors

Key Insight

Early metaphors for software development, such as 'writing code,' portray a simplistic process akin to drafting a casual letter, implying minimal formal planning and a largely solitary effort. This perspective, though adequate for small, individual projects, proves insufficient for large-scale systems where software is rarely ever truly 'complete'—with up to 90 percent of development effort, and typically two-thirds, occurring after its initial release—and where originality is often less valued than the strategic reuse of existing design ideas, code, and test cases. Fred Brooks's influential advice, 'Plan to throw one away; you will, anyhow' (1995), while popular, is deemed poor guidance for the development of costly and complex software, a sentiment echoed by Craig Zerouni's retort, 'If you plan to throw one away, you will throw away two.' Similarly, the 'software farming' metaphor, suggesting that software creation resembles planting seeds and growing crops incrementally, falls short. While the underlying technique of incremental development is highly valuable, the farming analogy itself is weak, uninformative, and difficult to extend appropriately, often wrongly implying a lack of direct control over the software's evolution.

A more insightful and closely related metaphor is 'software accretion,' which denotes growth by gradual external addition, much like an oyster forming a pearl from small amounts of calcium carbonate or land expanding through the deposit of waterborne sediment. This metaphor accurately embodies incremental, iterative, adaptive, and evolutionary development approaches. In this model, one first constructs the simplest functional 'skeleton' of a system—a version that runs but may initially utilize dummy classes. Subsequently, real functionality, encompassing input, data manipulation, and output, is added bit by bit until a complete system emerges. This approach has strong anecdotal and documented support; Fred Brooks (1995) acknowledged incremental development as a radical improvement to his practice following 'The Mythical Man-Month,' and Tom Gilb (1988) laid the groundwork for modern Agile methodologies with his concept of 'Evolutionary Delivery.' The strength of accretion lies in its precise depiction of incremental development without overpromising or allowing for inappropriate conceptual extensions.

The 'building software' metaphor stands as the most useful and comprehensive, aligning seamlessly with the concept of accretion and providing detailed practical guidance. Its application adapts to scale: constructing a simple structure, like a doghouse, requires minimal planning and allows for easy error correction, mirroring small software projects where refactoring 1000 lines of code is manageable. For complex structures, such as a house, the process involves defined stages: problem definition, architectural design, detailed blueprints, physical construction, optimization, and rigorous inspections—paralleling comprehensive software development stages. In both activities, labor constitutes the main expense, not materials; consequently, meticulous design is paramount to prevent costly rework. The principle of reuse is also vital: purchasing prefabricated components (e.g., washers, cabinets) directly corresponds to utilizing high-level language features and pre-built libraries (e.g., container classes, UI components). Customization for 'first-class' products in both fields also finds parallels. Appropriate planning, though not necessarily exhaustive, ensures flexibility for future detail changes and prevents major problems. This metaphor further explains why diverse projects necessitate different development approaches (e.g., a toolshed versus a nuclear reactor), and how structural changes in a program incur higher costs than peripheral modifications. For extremely large projects, both construction types demand over-engineering, meticulous planning (e.g., the Empire State Building's 15-minute delivery window for materials), and extensive documentation, such as a software system with one million lines of code requiring an average of 69 kinds of documentation.