Evolution of Software Design and Architecture
# CS446/CS646/ECE452 Software Design and Architecture, Pengyu Nie
# Software Design is a Moving Target
# The bottleneck in software engineering keeps shifting as we solve old problems and discover new ones.
1980s
Code Structure
OOP, high-level PLs
2000s
Process & Testing
agile, automated testing, CI/CD
2010s
Deployment & Operation
cloud native, microservices/serverless
2020s
Specification & Verification
AI, ?
What's considered "the hard part" keeps changing. I. No Silver Bullet
# 1980s
Code Structure
OOP, high-level PLs
2000s
Process & Testing
agile, automated testing, CI/CD
2010s
Deployment & Operation
cloud native, microservices/serverless
2020s
Specification & Verification
AI, ?
No Silver Bullet—Essence and Accidents of Software Engineering
- Roadmap: four publications, each from a moment of major change.
- For each: context (what problem?), key insights, connection to this course.
- Notice how each publication responds to a different bottleneck. Context: The Software Crisis
# Hardware was booming:
Moore’s Law Computing power growing exponentially Software was falling behind:
No equivalent “Moore’s Law” for productivity Projects routinely late and over budget Defect rates stubbornly high “There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.”
- 1960s–80s: hardware doubling every couple of years (Moore's Law, 1965), but software still failing at alarming rates — "the software crisis."
- Brooks asked: is there a single breakthrough that could give 10x improvement in productivity?
- His answer: no, and here's why. Essential vs. Accidental Difficulties
# Accidental difficulties come from hardware constraints, awkward programming languages, tools, etc.
Essential difficulties are inherent to the software design problem itself.
“The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions.”
- Brooks' central insight: two types of difficulty.
- Accidental: from tools, languages, hardware — can be solved with better tools.
- Essential: inherent to the problem itself. Software must conform to the messy real world. Requirements change. Structure is invisible.
- No tool can remove essential complexity.
- Connection to this course: "essence" = architecture + design patterns. What we studied all term IS the essential complexity. Potential “Silver Bullets”
# Brooks examined technologies that promised breakthroughs.
Each one primarily addressed accidental , not essential complexity:
High-level languages (Ada, etc.)Removed machine-level accidents Object-oriented programming Better code structure, but same conceptual complexity AI and expert systems 1980s AI: speech/image recognition, rule engines “Automatic” programming Only works when you can specify the problem precisely — which IS the hard part Graphical programming Software is not inherently spatial Program verification Verifies code meets spec; doesn’t help write the spec - High-level languages helped, but didn't help figure out WHAT to build.
- OOP helped organize code, not reduce conceptual complexity.
- 1980s AI: pattern recognition and expert systems, nothing like today's LLMs.
- Automatic programming is circular: specifying precisely IS the hard part.
- Program verification: proves code matches spec, but doesn't help write the spec. (This will come back in the AI section.)
- None useless, all helped with accidental complexity, but none delivered 10x. Suggestions
# Instead of seeking silver bullets, Brooks recommended:
Buy versus build — reuse existing software whenever possible
Today: open-source ecosystems, package managers, SaaS Requirements refinement and rapid prototyping — invest in understanding the problem
Today: user research, MVPs, design thinking Incremental development — “grow, not build, software”
Today: agile sprints, continuous delivery Great designers — invest in people, not just tools
Today: staff/principal engineers, architecture reviews - Remarkably prescient recommendations.
- "Buy vs build" → npm, pip, Maven, massive open-source ecosystems.
- "Requirements refinement" → agile, user-centered design.
- "Grow, not build" → iterative development, continuous delivery.
- "Great designers" → staff/principal engineer career tracks.
- All four became mainstream. But they evolved in ways Brooks couldn't have predicted. II. The Agile Revolution
# 1980s
Code Structure
OOP, high-level PLs
2000s
Process & Testing
agile, automated testing, CI/CD
2010s
Deployment & Operation
cloud native, microservices/serverless
2020s
Specification & Verification
AI, ?
Manifesto for Agile Software Development
The Agile Manifesto
# February 2001: 17 software engineering practitioners met at Snowbird, Utah.
They represented competing lightweight methodologies
and found common ground in four values :
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
"While there is value in the items on the right, we value the items on the left more."
- 17 signatories included Kent Beck, Martin Fowler, Robert Martin, etc.
- They had been developing alternatives to waterfall independently (Extreme Programming, Scrum, etc.) and found common values.
- Note the wording: "over", not "instead of" — they're not anti-documentation, they're saying working software matters more.
- Direct response to heavyweight, documentation-driven processes of the 1990s. Key Agile Principles
# From the twelve principles behind the Manifesto:
Deliver working software frequently — weeks rather than monthsWorking software is the primary measure of progressWelcome changing requirements , even late in developmentThe best architectures emerge from self-organizing teams At regular intervals, the team reflects and adjusts Impact on design and architecture:
# Design+architecture is no longer a phase completed before coding.
It becomes a continuous activity that evolves with the software.
- "Welcome changing requirements" was revolutionary — waterfall treated requirement changes as failures.
- "Best architectures emerge from self-organizing teams" — challenged the ivory-tower architect model.
- Architecture becomes evolutionary, not prescriptive.
- Retrospectives — something your teams hopefully practiced during the project. Continuous Integration
# “Continuous Integration is a software development practice where members of a team integrate their work frequently… Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.”
— Martin Fowler’s blog
Key practices:
Automate the build (with tests) Keep the build fast Every commit triggers a build on an integration machine Fix broken builds immediately Automate deployment when appropriate - Core insight: "frequency reduces difficulty" — merging daily means small conflicts; merging monthly means enormous ones.
- These practices map to what we covered in the CI workshop: Git, CI pipelines, test suites, etc.
- In 2006, many teams still did manual integration weekly/monthly. This article gave a concrete blueprint. Impact on Software Design and Architecture
# Agile + CI enabled a new way of thinking about architecture:
Before: Big Upfront Design
Architect designs the system Hands off specs to developers Architecture is frozen early Changes are expensive and resisted After: Evolutionary Architecture
Architecture emerges from development Validated continuously by automated tests Small changes, frequently integrated Architecture decisions can be revisited - Before agile, architecture was like construction: blueprint first, build second, changes are expensive.
- Agile says software is more like a garden: plant, grow, prune, adapt.
- "Fitness functions": automated checks that guard architectural properties (e.g., no circular dependencies, response time under threshold). Requires CI to run continuously.
- Each era builds on the last — CI makes evolutionary architecture possible. III. Cloud Native Architecture
# 1980s
Code Structure
OOP, high-level PLs
2000s
Process & Testing
agile, automated testing, CI/CD
2010s
Deployment & Operation
cloud native, microservices/serverless
2020s
Specification & Verification
AI, ?
The Twelve-Factor App
Moving to Cloud
# Key milestones:
2006 : AWS S3 and EC2 launch2008 : Google App Engine2010 : Microsoft Azure GA2013 : Docker — portable containers2014 : Kubernetes — container orchestration, open-sourced by GoogleThe fundamental shift:
Servers went from “pets” to “cattle”
Pets: named, cared for, irreplaceable Cattle: numbered, interchangeable, disposable No more capacity planning for peak load Scale up on demand, scale down to save money This changed not just infrastructure, but architecture itself .
- AWS EC2 (2006): get a server in minutes instead of weeks, pay by the hour.
- "Pets vs cattle" captures the mindset shift: don't nurse a sick server, replace it.
- When servers are disposable and elastic, you can decompose applications differently — many small services instead of one big reliable server.
- This is what enabled microservices. The Twelve-Factor App (2011)
# Adam Wiggins distilled 12 principles for cloud-native applications:
Codebase : one repo, many deploysDependencies : explicitly declaredConfig : stored in the environmentBacking services : treated as attached resourcesBuild, release, run : strictly separatedProcesses : stateless and share-nothingPort binding : self-contained servicesConcurrency : scale via processesDisposability : fast startup, graceful shutdownDev/prod parity : keep environments similarLogs : treat as event streamsAdmin processes : run as one-off tasks- Became the de facto checklist for cloud-native apps.
- Each factor addresses a specific pain of cloud deployment.
- Key ones: stateless processes (horizontal scaling), config in environment (same code in dev/staging/prod), disposability (auto-scaling + zero-downtime deploys), dev/prod parity ("works on my machine" prevention).
- Maps to NFRs from this course: scalability, portability, reliability. Microservices
# Microservices
The article that named and defined the architectural style:
Monolith UI
Business Logic
Data Access
Single Database
One deployable unit
Microservices Independent services, own data, own deployment
Organized around business capabilities , not technical layers.
Each service communicates through simple protocols (e.g., HTTP/REST).
- Extends the server-client style we studied this term, taken to its logical extreme.
- Each service owns its data, deployment, and business capability.
- "Design for failure" — network calls will fail, services will go down; architecture must handle this.
- Only makes economic sense with cloud — spinning up new services must be cheap and fast. The Stack
# Each breakthrough built on the previous ones:
Year Innovation Enabled 2006 CI/CD Frequent builds, tests, releases 2006 AWS & Other Clouds Elastic infrastructure, on-demand scaling 2011 12 Factor Cloud + CI/CD, Cloud-native design principles 2013 Docker “Build once, run anywhere” 2014 Kubernetes Container orchestration at scale 2014 Microservices Independent service deployment
- Can't do microservices without CI/CD; can't do CI/CD without cloud. Each layer depends on the one below.
- Docker made packaging portable. Kubernetes solved orchestrating containers at scale.
- Accelerate (2018) brought data to DevOps: surveyed 30k+ professionals over 4 years, proved these practices cause better organizational performance.
- DORA metrics (deployment frequency, lead time, time to restore, change failure rate) are now industry standard. IV. Future of Software Engineering
# 1980s
Code Structure
OOP, high-level PLs
2000s
Process & Testing
agile, automated testing, CI/CD
2010s
Deployment & Operation
cloud native, microservices/serverless
2020s
Specification & Verification
AI, ?
The Future of Software Engineering
AI for SE
# AI for software development tasks has gone from research to daily practice:
Copilot-style assistants auto-complete code as you typeAI agents can implement features, fix bugs, write testsThe question is no longer “Can AI write code?”
The question is: What happens to engineering discipline?
- You've all used AI tools this term — Copilot, ChatGPT, Claude, etc.
- If AI writes code faster and cheaper, does engineering discipline become obsolete, or more important?
- The retreat's answer connects directly back to Brooks. The Rigor Has to Go Somewhere
# “If we stop caring about the code, our rigor has to move somewhere else.”
If coding is cheap, rigor moves to:
Specification : precisely defining what should be builtVerification : ensuring it’s correct, secure, and meets quality standardsGovernance : accountability, compliance, risk managementThis is Brooks’ essential complexity resurfacing:
AI handles the accidental complexity of writing code.
But the essential complexity of specifying what to build remains.
- Engineering discipline doesn't disappear — it moves to specification, verification, governance.
- This is Brooks' essential complexity, resurfacing 40 years later.
- AI handles accidental complexity (translating spec to code). Essential complexity (what to build, edge cases, trade-offs) remains a human problem.
- Requirements analysis, architectural reasoning, design trade-offs — these matter MORE now. Supervisory Engineering
# A new kind of engineering work is emerging as a “middle loop”
sitting between the inner loop of writing code (automated by AI) and the outer loop of CI/CD (automated once configured):
Directing AI agents toward the right goals Evaluating and validating agent output Calibrating trust (when to accept, when to verify) Encoding standards as constraints Defining safe operating boundaries - Sits between writing code and release management.
- The right column maps directly to what we studied this term.
- The vocabulary of software architecture becomes the language of human-AI collaboration. What’s Changing in SE?
# Rachel Laycock’s summary organizes the retreat’s takeaways into three dimensions:
People AI tools increase cognitive load , not reduce it — “velocity without understanding is not sustainable” Engineering role shifts toward supervisory work : agent orchestration & governance Decision fatigue is a real concernProcess Tier software by criticality — focus human review where it matters mostStrong CI/CD guardrails become even more important “Agent topologies ”: how agents fit into team structures and workflows Technology Safe, constrained languages may be better suited for AI-generated codeShift toward verification (formal methods, property-based testing) over inspecting code Self-healing systems informed by incident history- People: AI increases cognitive load paradoxically. More output, but more fatigue. Engineers shift from writing code to orchestrating and verifying agents.
- Process: Not all code needs the same rigor. Tier by risk, focus human review on critical paths. CI/CD pipelines need strong guardrails (functional + cross-functional testing). "Agent topologies" = how agents fit into team structures (analogous to "team topologies").
- Technology: Terse, type-safe languages constrain AI output better. Formal methods / property-based testing focus on behavior, not code. Self-healing systems use knowledge graphs of past incidents. Source code may eventually "disappear from view." Summary
# 40 years later, Brooks’ insight holds:
There is no silver bullet.
1980s
Code Structure
OOP, high-level PLs
2000s
Process & Testing
agile, automated testing, CI/CD
2010s
Deployment & Operation
cloud native, microservices/serverless
2020s
Specification & Verification
AI, ?
- Full circle to Brooks: no single technology eliminates essential complexity.
- OOP, Agile, Cloud, AI — each valuable, none a silver bullet.
- The bottleneck keeps moving, but the fundamentals endure: requirements, architecture, design patterns, trade-offs.
- Be the engineer who understands the "why," not just the "how." Tools change; judgment is timeless.
- Good luck with final presentations and your careers.