Software Is NOT Like Building a House

Our friends at Wired 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 unfortunate metaphor 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

• Customer Satisfaction: The top priority is to continuously satisfy the customer by delivering valuable software early and often.

• Embrace Change: Agile welcomes changing requirements, recognizing that they can provide a competitive advantage for the customer.

• Frequent Deliveries: Working software is delivered frequently, with a preference for shorter timescales, ensuring that progress is visible and usable.

• Collaboration: Business people and developers collaborate daily throughout the project to ensure alignment and responsiveness.

• Motivated Teams: Agile builds projects around motivated individuals, providing them with the necessary support and trust to excel.

• Face-to-Face Communication: Face-to-face conversations are valued as the most efficient way to convey information within development teams.

• Working Software as Progress: The primary measure of progress is the delivery of working software, emphasizing functionality over documentation.

• Sustainable Development: Agile promotes sustainable development, enabling teams to maintain a consistent pace indefinitely.

• Technical Excellence: Continuous attention to technical excellence and good design is crucial for agility and long-term success.

• Simplicity: Simplicity is valued, aiming to maximize productivity by avoiding unnecessary work.

• Self-Organizing Teams: Self-organizing teams are trusted to determine the best architectures, requirements, and designs.

• Regular Reflection and Improvement: At regular intervals, teams reflect on their performance and adjust their behavior to become more effective.

The Agile Manifesto serves as a vital resource for software development teams, providing them with a flexible framework to steer their project management processes and uphold Agile best practices. This foundational document also elucidates the core values of Agile project management, empowering teams to prioritize their activities and align their goals. For instance, software developers can place customer satisfaction at the forefront, guiding all project plans accordingly.

Nevertheless, caution should be exercised regarding what is commonly referred to as the "Agile Industrial Complex." This term pertains to individuals and organizations that impose standardized Agile practices on teams, rather than allowing them the autonomy to determine what suits their needs best. Recognizing that there is no one-size-fits-all approach to project management, and attempting to impose an ill-fitting methodology will not yield the desired outcomes. Martin Fowler, one of the founders of the Agile Manifesto, emphasizes that "even Agile proponents wouldn't claim that Agile is universally the best solution."

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.