Don’t Let Your Application Turn into Another Winchester Mystery House

Some time ago when I was living in Silicon Valley, I often drove by a curious-looking structure called the Winchester Mystery House every day on my way to work. The Winchester Mystery House is a San Jose mansion that was once the home of Sarah Winchester, the widow of William Winchester, and the heir to the Winchester Rifle fortune. Originally purchased in 1884 as an unfinished eight-room farmhouse, it was expanded over the course of 36 years to an overall footprint of 24,000 square feet.  

Although it’s been years since I’ve seen it in person, I often think about that place when I consider the ramifications of Agile development and DevOps processes.

Every Agile process shares the same guiding principle: incremental software development. The basic idea is to build the minimum viable product (MVP) to solve the current business need and then incrementally add more features and capabilities based on feedback and experience. If all goes well, the product will evolve into exactly what you need it to be, and it will be done with a minimum of investment.

Meanwhile, there’s DevOps, which allows teams to integrate new products and features quickly and easily by relying on CI/CD (continuous integration and continuous deployment).

Combined, Agile development and DevOps make a potent pair. They shorten the feedback cycle dramatically, allowing you to constantly adjust your applications to meet the needs of your customers.

Yet, whenever I think of Agile and DevOps, my mind can’t help but take me back to the specter of the Winchester Mystery House.

Here’s why.

The dangers of building without a blueprint

Although it started out as a relatively modest farmhouse, the Winchester mansion ultimately expanded to a total of 160 rooms. Each individual room is exquisitely crafted and beautiful in its own way. But there’s a problem. As far as we know, Sarah Winchester never had a grand plan for the house’s overall design. The house was built incrementally and obsessively. There was no blueprint for where it was ultimately headed.

The Winchester Mystery House may have been able to take advantage of the finest builders and craftsmen of the time, but what it sorely lacked was an architect. Internally, each room may be precious and beautiful, but externally it’s a chaotic sprawl.

Incrementally building your software leaves you subject to the same pitfalls that Sarah Winchester faced. What is lost in this laser-like focus on continuous improvement is a solid systemic architecture to guide your product development and ensure that fundamental issues, such as resiliency and scalability, are part of the equation. Without them, each change you make increases your technical debt. As your needs grow, your system becomes harder to support, harder to expand, and less capable. Any short-term benefits you may derive from this approach are offset by huge long-term costs.  

Make no mistake, there’s nothing wrong with incremental development and deployment. They can be critical in adapting to customer feedback. But this is just part of the total picture. The missing piece in many an application development project is architecture. There’s no reason why the two can’t amicably coexist. Even if you are building your product incrementally, it is vital to devote some of your focus on an overall architecture strategy, and crucial to consider how individual decisions and shortcuts made in the name of expediency will impact that strategy.

Appoint someone to “own” the long-term architectural vision

The easiest way to ensure that architecture remains top of mind is to designate someone whose job is to “own” the overall architectural vision of your product, and it’s important that whomever you choose remains outside of the Agile process. In that way, when the rest of the team is focused on quickly adapting and adjusting the product to meet changing customer needs, you’ll have one person who continues to maintain a long-term vision of what you want to build, and who can make sure that short-term decisions don’t have unwelcome long-term implications and costs.

Some might point to the Winchester Mystery House and see it as an example of the benefits of Agile development without an architect. After all, the house is one of the most popular tourist destinations in San Jose. And yet, what is it that makes the mansion such a hit with visitors? It isn’t the excellence in craftsmanship and building. It’s the haphazard nature of the house —it has doors and stairs that lead to nowhere and windows that provide views of other rooms. These oddities lead to the impression that the house is haunted, and this is what draws people to the house.

Agile development and continuous integration and deployment have quickly become necessities in this era of constant adaptation and adjustment. But if you want to avoid turning your application development project into a costly, sprawling nightmare, do what Sarah Winchester failed to do—be sure to designate an architect.

More articles from Lee Atchison:


Ask SAILee!

Do you have a question about software architecture, cloud computing, application modernization, or IT complexity? Ask SAILee! SAILee is the AI voice of Lee Atchison, the noted cloud architect, author, and leader in architecting scalable applications. Ask any question, and you'll get answers based on the books, articles, and other content created by Lee Atchison.

Ask SAILee