Skip to main content

Command Palette

Search for a command to run...

Steve Jobs’ Lesson for Software Architecture: Experience First, Technology Second

Updated
3 min read
Steve Jobs’ Lesson for Software Architecture: Experience First, Technology Second

In 1997, during a Q&A at Apple’s Worldwide Developers Conference, someone tried to corner Steve Jobs with a deeply technical question about OpenDoc. Jobs paused for a moment, then gave an answer that has since become legendary:

“You’ve got to start with the customer experience and work backwards to the technology — not the other way around.”

He wasn’t just talking about product design. Jobs was articulating a principle that reaches deep into the foundations of software architecture — one that applies equally to how we design systems, not just how we sell them.


Experience-first and Model-first

Where Jobs sought to reach the largest possible audience through an intuitive experience, the object-oriented architect seeks to reach the clearest possible model of a domain before writing a single line of code. Both approaches share the same philosophy: clarity first, mechanics second.

In Object-Oriented design, you begin not with frameworks, data flows, or algorithms, but with the model — the vocabulary, behaviors, and relationships that define the business domain. Only when that model makes sense do you work backward to the implementation details.

This reversal of order is crucial. When you start with the model:

  • You find the simplest and smallest implementation that fits the business reality.

  • You reduce framework dependencies, because your system revolves around meaning, not mechanics.

  • You gain flexibility, since the model — grounded in business logic — adapts naturally as requirements evolve.

  • You minimize maintenance, because each part of the code has a clear, enduring reason to exist.


The Procedural Trap

Procedural and functional paradigms often start with “how” — how to process data, how to transform inputs into outputs, how to compose functions efficiently. This approach can be powerful for computation-heavy problems but brittle in evolving business contexts. Every new requirement forces you to reopen the machinery and thread in another special case.

OO, when done properly, inverts this. You start with what the business domain looks like and why it behaves that way. The “how” emerges as a natural consequence.


From Users to Models

Jobs’ philosophy of working backward from experience is, in essence, a philosophy of empathy — understanding the human at the other end of the design. Object-Oriented design is empathy applied inward: understanding the domain expert, the business, and the conceptual world the software must live in.

Both share the same outcome: elegance through understanding.

When we design software the way Jobs designed products — starting from the experience (or model) and working backward to the technology — we create systems that are simple, resilient, and meaningful. And just as great products feel inevitable once you hold them, great architectures feel inevitable once you read the code.


The best architectures, like the best products, don’t impress by complexity — they disappear behind clarity.

Start with the model, not the mechanism. Start with the experience, not the engine. Because in the end, software isn’t built to show what we can do with technology — it’s built to make technology serve what we mean to do.

Code that starts with technology ages with it.

Code that starts with meaning endures beyond it.

More from this blog

E

Effective software engineering

69 posts

25 years modeling domains in enterprise & startups. Helping teams build systems that evolve, not explode. DM me if you want clarity before chaos. Model first. Code second.