It's time to tailor your programming metaphors
Connecting state and local government leaders
Is your project more like a garden or a building? The choice of metaphor should be tailored to the type and size of the project you are undertaking.
Is programming software more like gardening or construction? This debate flares up every so often in programming circles, on sites such as Hacker News or in dueling blog posts.
It appears that many agile practitioners prefer the gardening metaphor, whereas developers in the Big Design Up Front (BDUF) school prefer a construction metaphor.
Personally, I think that the choice of metaphor should be tailored to the type and size of the project you are undertaking. In other words, you need to pick the right metaphor for your project. If you don’t, it could lead to unfortunate consequences.
For example, is healthcare.gov development more suited to a garden metaphor or an airplane allusion? We know it took off on schedule but then quickly crashed and burned. Or was it an airplane in terms of complexity that tried to pretend (and be built as if) it was a garden?
Let’s take a moment to peel back each metaphor a bit to see which is more fitting.
The idea of programming as gardening is generally attributed to Andy Hunt and Dave Thomas from their book The Pragmatic Programmer: From Journeyman to Master. The key attribute the authors bring out via this metaphor is the organic nature of a garden – that it grows and is not mechanical or perfect but dynamic and changing.
This aligns well with agile software development where developers attempt to grow software by building it a little bit at a time, water it with constant communication with the customer and prune it with constant testing.
The advantages of using this metaphor as a project description are flexibility in the face of change, having working software rapidly and building reliable software in layers. The cons of the garden metaphor are its simplicity, a de-emphasis on design/architecture and that it’s programmer-centric.
The construction metaphor, on the other hand, is based on traditional engineering processes that involve a set of blueprints (a design), solid architectural principles and a finished product that matches the design. This metaphor is championed by well-known author Steve McConnell in his book Code Complete: A Practical Handbook of Software Construction, Second Edition.
The pros of the construction metaphor are that it is common to other engineering disciplines, its focus is on design and architecture and it suggests complex projects like large building and bridges. The cons of are its suggestion of inflexibility to rapid change, a tendency to budget overruns and a requirement for large amounts of documentation.
So, which of these metaphors best describes healthcare.gov? How should we judge which metaphor works better? Is it possible that both work but in different situations?
The key distinctions in both metaphors seem to be around change and design. In other words, can what you are trying to build be designed reliably? For example, has it been done before?
Other key characteristics of software that affect your choice of metaphor are change and variability – do you know what you want or are you innovating and thus expecting experimentation and discovery?
Given this, I would recommend that you choose the right metaphor to match the scope, complexity and level of innovation in your objective software. In general, small scopes and high-levels of innovation are well served by software gardening; whereas large scopes and predictable architectures are better served by software engineering.
Michael C. Daconta (mdaconta@incadencecorp.com) is the Vice President of Advanced Technology at InCadence Strategic Solutions and the former Metadata Program Manager for the Homeland Security Department. His new book is entitled, The Great Cloud Migration: Your Roadmap to Cloud Computing, Big Data and Linked Data.
NEXT STORY: Relief for integration headaches