Abstraction: hiding unnecessary detail

When you drive a car, you use a steering wheel, an accelerator, and a brake pedal. You do not need to think about fuel injection, engine timing, or the exact mechanical steps that turn the wheels.

The car gives you a simple way to control something much more complicated because someone designed it so you could use it without understanding everything happening underneath.

This deliberate hiding of unnecessary detail is called abstractionConcept · lights on your mapabstractionThe deliberate hiding of unnecessary complexity behind a simpler way of using something. A “Pay” button is an abstraction over card networks, fraud checks, and bank transfers. Software is built as abstractions stacked on abstractions, each layer offering a simple surface over the machinery below..

What is abstraction?

An abstraction gives you a simpler way to interact with something complicated.

The brake pedal is an abstraction. You press it to slow the car down without personally controlling every mechanical part involved in braking. A light switch is another, since you flip it without needing to understand the electrical system inside the walls.

Software works the same way, presenting people with simple buttons, screens, and actions while hiding much of the complexity required to make them work.

When you tap Pay in a coffee app, you do not need to know how the application communicates with a payment company, how the card network contacts your bank, or how the transaction is recorded. The button gives you a simple way to begin a complicated process.

Software is built in layers

Software is often described as layers of abstraction, where each layer handles certain responsibilities and provides a simpler way for the layer above it to use its capabilities.

For example, the engineer building a checkout page may not need to understand every internal detail of the banking network. The checkout system can send a payment request to a payment provider and receive a result such as approved or declined.

The payment provider hides much of the underlying complexity, so the engineer only needs to understand how to use the connection between the two systems correctly.

This does not mean engineers blindly trust everything beneath their work, and they still need to understand the behavior, limitations, and possible failures of the tools they depend on. But they usually do not need to understand every internal detail of those tools.

Abstraction allows people to focus on the part of the problem that matters to them.

How engineers understand complicated products

Large software products can contain millions of lines of code, many databases, numerous services, and infrastructure spread across different locations.

No single person usually understands every detail equally well, so people develop different levels of understanding instead.

An engineer may understand one part of the product deeply, know how it connects to nearby parts, and have a higher-level understanding of the rest. Another engineer may specialize in a different area.

Abstraction is what makes this possible. People can work with a complicated system by understanding its major parts and how those parts interact, without keeping every low-level detail in their heads at once.

You already do this when using technology. You can send an email without understanding exactly how it travels across the internet, and you understand what the email system allows you to do even if its internal machinery remains hidden.

What is a system?

A systemConcept · lights on your mapsystemA set of connected parts that work together to accomplish a purpose: “the payment system,” “the notification system.” Engineers use the word constantly and loosely; the skill is noticing which system a conversation is about. is a set of connected parts that work together to accomplish a purpose.

A coffee application is a system whose purpose is to allow customers to select, purchase, and receive drinks.

Inside that application, there may be smaller systems responsible for:

• Processing payments
• Managing customer accounts
• Sending notifications
• Tracking rewards
• Delivering orders to café employees

Each smaller system performs a particular role while contributing to the larger product.

What is a component?

A componentConcept · lights on your mapcomponentOne part of a larger system. Every component can itself be treated as a system and opened up into smaller components of its own. The payment system is a component of the coffee app, and a system in its own right. is one part of a larger system.

The payment system, notification system, and rewards system can each be considered components of the coffee application.

But the same thing can be viewed as either a system or a component, depending on your level of focus.

From the perspective of the entire coffee application, the payment system is one component. If you zoom in on the payment system itself, it becomes a system made of its own components, such as payment forms, fraud checks, bank connections, and transaction records.

This is similar to looking at a city on a map. From far away the city appears as one part of a country, but when you zoom in, it becomes a system of its own, containing neighborhoods, streets, buildings, and transportation networks. The city never changed — only how much of it you asked to see.

Different levels of detail

Abstraction allows people to view a system at the level of detail that is useful for the current conversation.

A product manager discussing checkout may only need to see a few major components:

Customer app → Payment system → Bank

An engineer investigating a failed payment may need a more detailed view:

Checkout page → Payment service → Fraud check → Card network → Bank

Both views can be correct, since they are showing the same system at different levels of zoom.

This is why technical diagrams often contain boxes connected by arrows. Each box represents a component whose internal details have been temporarily hidden so that the reader can focus on how the larger system fits together.

Boundaries between components

Every abstraction creates a boundary, and the boundary determines what a component is responsible for, what details it hides, and how other parts of the system interact with it.

A payment provider, for example, may allow an application to submit a payment and receive a result, but the coffee app does not control how the provider communicates with banks internally. That responsibility lives across the boundary.

When engineers discuss where a boundary should be drawn, they are often deciding:

• Which component should own a responsibility
• Which details should remain hidden
• What information should cross between components
• How much one component should depend on another

You do not need to design these boundaries yet. For now, it is enough to recognize that complicated software becomes manageable when it is divided into parts with clear responsibilities.

Why abstraction matters throughout technology

Abstraction will appear repeatedly throughout this curriculum.

An application hides much of the complexity of the computer beneath it, and an operating system helps applications use hardware without controlling every physical component directly. An API gives one piece of software a controlled way to use another system, and cloud services allow companies to use computing resources without managing every physical machine themselves.

In each case, abstraction provides a useful capability while hiding details that the user does not need for the immediate task.

The mental model to remember

Abstraction is the deliberate hiding of unnecessary complexity behind a simpler way of using something.

A system is a group of connected parts working together toward a purpose.

A component is one part of a larger system, although it may also contain smaller components of its own.

When a technical product feels overwhelming, try changing your level of zoom. First identify the major components and how they connect. You can examine the details inside an individual component only when those details become relevant.