Why Architecture Matters — Part 1
Ignoring software architecture is crippling software development
Why the failure to understand and fulfill the purpose of software architecture is crippling corporate software development and inflating development backlogs and costs.
“The goal of software architecture is to minimize the human resources required to build and maintain the required system.
The architecture of a software system is the shape given to that system by those who build it. The form of that shape is in the division of that system into components, the arrangement of those components, and the ways in which those components communicate with each other.
The purpose of that shape is to facilitate the development, deployment, operation, and maintenance of the software system contained within it.”
— Robert C. Martin, Clean Architecture
The Agile Revolution
Development agility is a very good thing. In 2001, seventeen highly experienced software developers met at a resort in Snowbird, Utah, to discuss lightweight development methods. The Manifesto for Agile Software Development was the result. Agile development is the software analog of lean manufacturing. Agile methodologies like Scrum and Kanban have revolutionized corporate software development.
Even positive revolutions are not pain-free and the Agile revolution has not been without unintended consequences. Among those consequences has been a disruption of traditional software architecture and engineering practices, which has resulted in nonlinear increases in development backlogs and costs. Let’s take a look at why that has happened.
What Went Wrong?
If development agility is such a good thing, why isn’t it working as intended? Why are backlogs and costs increasing even though Agile’s highest priority is to satisfy the customer through early and continuous production of valuable software — and its frameworks are intended to promote sustainable development?
Agile is the best way to approach software development that has yet been tried. But problems arise because commercialized “Agile methodologies” are sold to general management, not to developers. They are oversold and oversimplified to appeal to that management audience.
They focus upon measuring success in terms of functionality delivered to the customer/end-user — which is important. However, they downplay the value of activities like architecture and system design which enable the economical delivery of the desired user functionality. The unintended consequence of that measurement bias, growing technical debt, is inevitable. People do best what the boss is watching.
Cascading Complexity
Software is inherently complex. The larger a system grows, or the more it has been changed, the more complex it tends to get. Software architectures and the designs they facilitate are our primary tools for managing complexity.
As shown in Figure 1, application complexity increases dramatically as the number of things that make up the application and the connections between them increase.
Without sufficient attention to software quality — architecture, design, coding practices, and testing — the technical debt from unmanaged complexity will quickly consume available development resources.
Pay Now or Pay More Later
There are fundamental reasons we use separate terms for hardware and software. We write software to instruct hardware to implement the behaviors we need.
To be “soft”, software must be easy to change — because hardware is so “hard” and expensive to change. Can you imagine having to design and manufacture a new CPU because an application feature needed to change? The costs would be prohibitive!
Writing code just isn’t that difficult. Writing code that is easy to change and plays well with the rest of the system is harder. Keeping software “soft” requires utilizing appropriate architecture and design, understanding applicable constraints, and having sufficient discipline to honor those constraints.
We can pay for software quality up front and reap the benefits for the life of the code — benefits like stable development costs, economical to enhance applications, and predictable development schedules.
Or we can pretend that quick and dirty actually works for software development and then pay for it for the life of the code — with ever-increasing development costs, expensive to change applications, and unpredictable development schedules with ever-growing backlogs.
It is a clear and simple choice — pay for software quality now or pay for the lack of it, with interest, forever. Which choice do you think makes the best business sense?
Though we are supposed to be the technical professionals, we developers have too often been complicit, with management, in making the wrong development choices. Our credibility with management has rightly suffered for that. We desperately need to change that perception if we are to break the vicious cycle of technical debt.
Thank you for your time.
Why Architecture Matters — Part 2 takes a deeper look into exactly why and how software architecture can help fulfill the promise of Agile and start to tame development backlogs.
Composable Services dives into the architectural patterns that can help to make software systems more Agile.
