Form follows fiasco
Why software architects should stick with their projects
Last weekend, I took my daughter to an antique bookstore/coffee house where we came upon a book called "Form Follows Fiasco: Why Modern Architecture Hasn't Worked." This book is not about software architecture. It's about actual architecture, which involves buildings that might collapse if not built right.
The title of the book spoke to me. Luckily, in software engineering, with the notable exception of avionics and healthcare software, we don't build things that might collapse and harm people. We might do silly things like introduce a software bug that caused a financial firm to collapse. For the most part, though, most of us are unlikely to encounter a software problem that results in significant financial loss, personal injury, or death.
Throughout my career, I've become acutely aware of how, more often than not, glorious software architectures collapse under their weight. I've inherited projects whose original developers and architects have long left, leaving behind an unmaintainable mess that doesn't scale.
It's one thing for developers to change jobs before a project sees the light of day. Most of the time, no matter their good intentions, they don't have much control over the management and architecture of their project.
Software architecture must balance out the needs of conflicting stakeholders. Developers want to be productive and have their ideas heard. Project managers must participate in the architecture decisions that may impact the process and delivery. Product owners need to stay involved to ensure that the architecture meets the product vision.
A well-designed object-oriented monolith is not worth its poetic structure if the team working on it cannot grow or scale. Architecture decisions that seem elegant at the start of the project often prove disastrous when deployed to production and face the pressure of real-world utilization.
A software architect is like a captain. They go down with the ship. An architect should never be one of the first to jump a sinking ship that an unmaintainable architecture can become.
When I interview candidates for architect positions, I insist on asking them to describe a project they saw from start to finish. I ask them to explain what decisions they made and why. What pains did they experience when the project launched into production, and what did they do to solve them?
Form follows fiasco.
All architects should affix that slogan and keep it in front of them. If your project hasn't yet experienced a fiasco, you haven't achieved its proper form. A software architect who leaves their project before it can experience a fiasco is not much different from a ship captain who disembarks before the ship has even sailed.