Why Maintainability Should Be the Primary Goal of Software Architecture

Evaluating the quality of an architecture is highly subjective; without a common standard, debates about performance, security, scalability, maintainability, and cost become endless, and no consensus can be reached.

Because there is no unified metric, the author proposes using the fulfillment of the architect's design objectives as the benchmark: if a system meets those goals, its architecture can be considered good.

The article illustrates that different systems have different priorities—e.g., a missile‑launch system demands absolute stability and rapid response, while everyday software often compromises on cost and accepts bugs—highlighting the inevitable trade‑offs between reliability, speed, and expense.

Consequently, a pragmatic approach is to accept reasonable compromises and focus on a single standout quality: maintainability, which includes but is not limited to scalability.

Personal experience maintaining a ten‑year‑old logistics system written in multiple languages shows how fixing one bug can create another, underscoring the high maintenance cost and the prevalence of a development model where teams disband after delivery, leaving only junior developers to handle ongoing upkeep.

The author challenges the common blame placed on "requirement changes," arguing that software’s inherent modifiability actually drives continuous change, and that embracing change is essential for long‑term success.

To achieve maintainability, the author suggests practical choices such as selecting an appropriate language (e.g., object‑oriented C# instead of low‑level C for performance‑critical needs) and treating design patterns as lubricants that address local architectural flaws rather than as mandatory building blocks.

Effective module division—balancing neat, hierarchical layers with flexibility—is crucial; overly rigid "one‑size‑fits‑all" layers can hinder adaptability, while finer‑grained modules allow the system to evolve more gracefully.

Beyond code, good documentation, solid project‑management processes, and alignment with the development team’s skill set are necessary, but the ultimate purpose of architecture is to make the code smarter and let programmers focus on business logic, treating developers as replaceable components to ensure the system remains healthy over time.

Original source: Freedom Fly Blog