What Software Design Is

Between knowing what to build and actually writing the code, there's a step that beginners often skip and professionals never do: design. Design is deciding how the software will be shaped — what its parts are, how they fit together, and which details to hide — before the typing starts.

Its two core tools are abstraction (hiding complexity behind a simple interface) and modeling (representing the real-world thing you're building in the structure of the code). Get the design roughly right and the code flows; get it wrong and you fight the code forever.

Think of a floor plan drawn before construction. It settles where the rooms and doorways go — not the brand of every nail. Design works at that level: the shape and the boundaries, not every last line.

Design Is Deciding Structure

At its heart, design is choosing the parts of the software and the relationships between them. Will there be a piece that handles users, another that handles habits, another that sends notifications? How do they talk? What does each one know about the others? These decisions are made — explicitly or not — before and during building, and they shape everything that follows. Design is thinking about structure ahead of committing to it in code.

Abstraction: Hiding Complexity

Abstraction means exposing what matters and hiding how it works. When you drive a car, you use a steering wheel and pedals — a simple interface — without knowing how the engine turns fuel into motion. Software does the same: a piece that "calculates a streak" can be used by the rest of the app through a simple call, while the messy details of how it counts days stay hidden inside. Good abstraction lets each part be used without understanding its internals — which is what keeps a big system comprehensible.

Modeling the Domain

Modeling is turning the real-world things your software is about into well-defined concepts in the code. A habit-tracking app is "about" users, habits, and daily check-ins — so the design names those as distinct things, decides what each one holds (a habit has a name, a schedule, a streak), and how they relate (a user has many habits; a habit has many check-ins). A clear model makes the rest of the design fall into place; a muddled one spreads confusion through every feature.

Some Design Always Happens

Here's the key truth: you can't avoid design, only avoid doing it deliberately. Skip the design step and the code still ends up with some structure — just one that emerged by accident, decision by hasty decision, usually into a tangle. Deliberate design isn't extra bureaucracy; it's choosing your structure on purpose instead of inheriting whatever the first rushed version left behind.

The Cadence team models their world as Users, Habits, and Check-ins, and they hide "how a streak is calculated" behind a single idea — call it getStreak() — so the rest of the app just asks for the streak without caring how it's worked out. When they later change the streak rules, only that hidden piece changes; everything that merely uses a streak is untouched. That's abstraction and a clean model paying off.