Software Is NOT Like Building a House

Our friends at Wired recently posted an article in their opinion section claiming that building software should be just like building a house.

No, no, no.

To be fair, this was just an opinion article and not part of the actual journal. But in my humble opinion, the article was wrong on many counts (and let’s just ignore the writer’s rather cheeky sentiments like, “Writing code without thinking is a recipe for bad code.” That’s just insulting and not terribly insightful...)

Writing software is not like building a house. This is an unfortunate metaphor that will confuse and frustrate new clients unfamiliar with custom-built IT software projects.

True, building a house, much like building custom software, does indeed require some upfront design, an architect, precision tools, and skilled people who are good at their craft. But that’s where the analogy ends—they are just loosely related concepts.

With custom software projects, expecting—and, frankly, embracing—change is a critical part of the process. Often what a client requests is not, in fact, what they want or need. Only after testing and playing with a system do the real requirements emerge. A critical part of agile process is adaptive planning, where feedback is welcome and priorities can change. This is the power of the agile process.

If you want a recipe for failure, go ahead and document every last detail of a project before ever starting development. In this waterfall method, teams will spend days, weeks, or even months in “analysis paralysis,” drawing up architectural documents, requirements specs, and designs before writing a single line of code. These documents will be written in stone and clients will go through a lengthy review and signoff process. The supposed goal of this spec-driven exercise is to make sure those rascally developers follow the plan and do exactly what they’re told, essentially commoditizing the process and eliminating all creativity and innovation. It also removes the ability for clients to react to feedback or change their minds, at least without an expensive change control process.

This is a surefire way to encourage finger-pointing between development teams and the customer. Not to mention, it will waste significant time and energy, and a lot of the client’s money.

Trust me, there is a better way.

The agile process starts with an element of upfront thinking, design, and planning. No (successful) software team jumps right into writing code on day one. For example, at TXI, we always begin our new projects with a Project Inception, allowing us the opportunity to brainstorm with our clients while building a shared understanding of the project requirements and product vision. This upfront planning is a vital first step, but as the Agile Manifesto reminds us, embracing change is more valuable than simply (or blindly) following a plan.

With that common vision and initial plan in place, we start developing the product iteratively, exposing progress, risks, and working software as we go. In this way, clients get to visualize progress NOT as a drafted spec document, but as actual functioning software that demonstrates real business value.

Through a constant feedback loop the customer can alter the direction of the project to align with their changing priorities and business needs. This level of control and quick response to user feedback allow for more rapid development and significant reduction in waste in the development process.

This does not mean that the agile process doesn’t encourage specs or documentation. Indeed, that level of detail still plays an important part in the process. But spending time in a heavy upfront specification stage will not lead to success for any client in software.

Now over ten years old, the Agile Manifesto is still relevant. And unlike building a house, a software project values:

• Working software over comprehensive documentation
• Responding to change over following a plan

The “building a house” metaphor is inaccurate at best and damaging at worst. People who go into a custom software experience expecting this behavior are just setting themselves up for life in a money pit. And no one wants to live in a house like that.

Graphic source: The Working Group

True, building a house, much like building custom software, does indeed require some upfront design, an architect, precision tools, and skilled people who are good at their craft. But that’s where the analogy ends—they are just loosely related concepts.

With custom software projects, expecting—and, frankly, embracing—change is a critical part of the process. Often what a client requests is not, in fact, what they want or need. Only after testing and playing with a system do the real requirements emerge. A critical part of agile process is adaptive planning, where feedback is welcome and priorities can change. This is the power of the agile process.

If you want a recipe for failure, go ahead and document every last detail of a project before ever starting development. In this waterfall method, teams will spend days, weeks, or even months in “analysis paralysis,” drawing up architectural documents, requirements specs, and designs before writing a single line of code. These documents will be written in stone and clients will go through a lengthy review and signoff process. The supposed goal of this spec-driven exercise is to make sure those rascally developers follow the plan and do exactly what they’re told, essentially commoditizing the process and eliminating all creativity and innovation. It also removes the ability for clients to react to feedback or change their minds, at least without an expensive change control process.

This is a surefire way to encourage finger-pointing between development teams and the customer. Not to mention, it will waste significant time and energy, and a lot of the client’s money.

Trust me, there is a better way.

The agile process starts with an element of upfront thinking, design, and planning. No (successful) software team jumps right into writing code on day one. For example, at TXI, we always begin our new projects with a Project Inception, allowing us the opportunity to brainstorm with our clients while building a shared understanding of the project requirements and product vision. This upfront planning is a vital first step, but as the Agile Manifesto reminds us, embracing change is more valuable than simply (or blindly) following a plan.

With that common vision and initial plan in place, we start developing the product iteratively, exposing progress, risks, and working software as we go. In this way, clients get to visualize progress NOT as a drafted spec document, but as actual functioning software that demonstrates real business value.

Through a constant feedback loop the customer can alter the direction of the project to align with their changing priorities and business needs. This level of control and quick response to user feedback allow for more rapid development and significant reduction in waste in the development process.

This does not mean that the agile process doesn’t encourage specs or documentation. Indeed, that level of detail still plays an important part in the process. But spending time in a heavy upfront specification stage will not lead to success for any client in software.

Now over ten years old, the Agile Manifesto is still relevant. And unlike building a house, a software project values:

• Working software over comprehensive documentation
• Responding to change over following a plan

The “building a house” metaphor is inaccurate at best and damaging at worst. People who go into a custom software experience expecting this behavior are just setting themselves up for life in a money pit. And no one wants to live in a house like that.