Why Software Engineering Still Lacks True Engineering Maturity After 30 Years

Definition of Engineering

The article opens with a definition from Mary Shaw and David Garlan's Software Architecture: Perspectives on an Emerging Discipline : engineering is "the disciplined application of scientific knowledge to resolve conflicting constraints and requirements for problems of immediate, practical significance." Five core elements are identified:

Creating cost-effective solutions – economical use of all resources, including money.

Addressing practical problems – solutions matter to customers outside the engineering discipline.

Applying scientific knowledge – using science, mathematics, and design analysis.

Building tangible artifacts – producing concrete, working systems.

Serving humanity – developing technology and expertise that support society.

Core Mechanism: Codification of Knowledge

Mature engineering differs from virtuoso performance or craft by systematically codifying scientific and practical knowledge. This codification achieves three things:

Eliminates absolute reliance on genius – engineering shares prior solutions rather than depending on virtuoso problem solving each time.

Enables ordinary practitioners to build reliably – average engineers can create complex, working, highly reliable systems.

Depends on handbooks and standards – like the Perry's Chemical Engineers' Handbook , mature disciplines rely on documented design equations, specifications, and standards that capture and disseminate design knowledge.

Software Engineering's Immaturity

3.1 Missing Knowledge Codification and Reuse Mechanisms

"In chemical plant design, when I need a heat exchanger I consult standard references and apply standard design equations… In software, unless my team happens to remember a past solution, I am forced to reinvent the wheel for every application." (Senior engineer from software engineering community)

Algorithms and libraries (math libraries, system calls) exist but are local, incomplete, and cannot support macro-architectural design and reuse.

3.2 Design Paradigm Gap: "Routine Design" vs. "Original Design"

Most software development is still treated as original design rather than routine design . Without codified, shared mechanisms, developers repeatedly build from scratch without sufficient reason, leading to high cost, schedule overruns, and defects.

3.3 Disconnect Between Computer Science and Practice

Computer science produces excellent theories (formal specification, parser generators), but packaging them into industrial-grade tools and handbooks for daily engineering use takes ~20 years. Practice often operates independently of organized scientific knowledge.

Progress Over 30 Years (1995–2025)

Abstraction-Level Leaps

From 1990s components and connectors to today's microservices , cloud-native declarative resources , and agent intent . Each leap hides lower-level details, letting developers work at larger cognitive granularity.

Knowledge Sedimentation Lifecycle

Early ad-hoc phase gave way to pattern handbooks (GoF Design Patterns , architecture patterns). Reusable systems now exist: Spring, Kubernetes, databases ; architectural styles (microservices); component/connector libraries (REST, gRPC, message queues); and documented practices.

Development Platforms and Tools

Full-lifecycle platforms: CI/CD pipelines, GitHub/GitLab/Gerrit, program analysis tools, collaborative IDEs, automated testing, and now Code Agents .

Persistent Gaps: Architecture Remains a Craft

1. No Unified Architecture Description Language

Formal ADLs have faded in general industry due to high cognitive/maintenance cost and the "two-skin" problem: architecture documents stay on paper while code iterates rapidly, with no strong bidirectional sync. Lightweight alternatives now used: ArchUnit , C4 model , 4+1 view model , ADR (Architecture Decision Records) .

2. Architecture Knowledge Maintenance Still Non-Standardized

Four key aspects lack systematic organization and reuse:

Architectural styles & design vocabulary

Design space & selection rules (design decisions)

Domain-specific reference architectures

Formal or informal visual architecture topology

3. Lack of Quantitative Architectural Design Models

Major architectural choices (e.g., "Should a microservice system have 20 or 50 services in 2026?") still have no mathematical equations or quantitative prediction models . The industry relies on senior architects' intuition or blindly copying "big-company practices" – classic experiential craft trial-and-error. Reference: Software Architecture: The Hard Parts .