Scrolls
7 min read
On this page

Modular Thinking

Modular thinking is the practice of building solutions from self-contained, reusable parts. Instead of creating a unique solution for every problem from scratch, you design pieces that can be combined, swapped, and reused across different contexts. It is the difference between building with LEGO bricks and sculpting from a single block of clay.

What Modular Thinking Is

A module is a self-contained unit that does one thing well and connects to other modules through clear, standard interfaces. Modular thinking means designing your solutions so that the parts are:

  • Self-contained: Each module works on its own without depending on the internal details of other modules.
  • Reusable: A module built for one purpose can be used in other contexts without modification.
  • Replaceable: You can swap one module for another as long as it fits the same interface.
  • Composable: Modules can be combined in different ways to create different outcomes.
Non-modular approach:
  Build a custom, one-piece solution for each problem.
  Nothing transfers. Every new problem starts from zero.

Modular approach:
  Build reusable parts with standard connections.
  New problems are solved by combining existing parts
  with minimal new construction.

Everyday Examples

LEGO Bricks

LEGO is the definitive example of modular design. Every brick, regardless of size, color, or shape, connects through the same interface: studs on top, tubes underneath. This standardized connection means:

  • Any brick can connect to any other brick.
  • You can build a castle, a spaceship, or a bridge with the same pieces.
  • If you do not like the roof, you remove and replace it without rebuilding the walls.
  • Bricks from a set you bought ten years ago work with bricks you bought yesterday.

The power is not in any individual brick. It is in the standardized interface that makes everything compatible.

IKEA Furniture

IKEA has mastered modular thinking in physical products. Their kitchen system, for example, uses standardized cabinet boxes. Every cabinet has the same depth and the same mounting system. You choose your cabinet width, your door style, your handles, your hinges, and your internal organizers independently.

IKEA Kitchen Modules:

  Cabinet boxes:    Standard depths, multiple widths
  Doors:            Dozens of styles, all fit the same boxes
  Handles:          Hundreds of options, standard mounting holes
  Hinges:           Soft-close or standard, same attachment
  Internal fittings: Pull-out drawers, shelf inserts, dividers
  Countertops:      Multiple materials, standard dimensions

  Mix and match any combination.
  Replace doors in 5 years without changing cabinets.
  Add organizers later without modifying anything else.

Clothing & Wardrobe Capsules

A capsule wardrobe is modular thinking applied to getting dressed. Instead of owning outfits (fixed combinations), you own pieces that mix and match.

  • Five tops, five bottoms, and three layers create dozens of distinct outfits.
  • Replacing one worn-out shirt does not require replacing anything else.
  • Adding a new piece multiplies your options rather than adding just one more outfit.
  • Everything works together because you chose a compatible color palette (the "interface").

Cooking with Base Recipes

Experienced cooks think modularly. They master base preparations that combine in many ways.

Base modules:
  - Basic vinaigrette (oil + acid + seasoning)
  - Roasted vegetables (any vegetable, same technique)
  - Cooked grain (rice, quinoa, couscous, same method)
  - Seared protein (chicken, fish, tofu, same approach)

Combinations:
  Grain + roasted vegetables + vinaigrette = grain bowl
  Protein + roasted vegetables + grain = dinner plate
  Protein + vinaigrette + greens = salad
  Grain + protein + broth = soup base

One new base module (a sauce, a topping) multiplies
the number of possible meals without starting over.

Standardized Shipping Containers

Before the 1950s, loading a cargo ship took days. Every item was a different shape and size, handled individually. Malcolm McLean's invention of the standardized shipping container transformed global trade.

Every container is the same dimensions, fits the same truck chassis, the same rail car, and the same ship slot. The contents do not matter. The interface (external dimensions and corner fittings) is what matters.

Before standardization:
  Each item loaded individually.
  Different trucks, different cranes, different ships.
  Loading time: days. Breakage: high. Cost: enormous.

After standardization:
  Everything goes in standard containers.
  Same trucks, same cranes, same ships worldwide.
  Loading time: hours. Breakage: minimal. Cost: fraction.

This is modular thinking at an industrial scale: standardize the interface, and the contents become irrelevant to the logistics system.

The Power of Standard Interfaces

The recurring theme in every example is the interface. Modules become powerful when they connect through standardized, well-defined interfaces.

  • LEGO bricks: studs and tubes
  • IKEA cabinets: standard dimensions and mounting systems
  • Wardrobe pieces: compatible color palette and style
  • Shipping containers: standard dimensions and corner fittings
  • Electrical outlets: standard plug shapes and voltages
A good interface defines:
  - What the module expects as input
  - What the module produces as output
  - How the module connects to other modules
  
A good interface does NOT specify:
  - How the module works internally
  - What materials it is made from
  - Who built it or when

This separation between interface (how things connect) and implementation (how things work internally) is one of the most powerful ideas in both engineering and everyday problem-solving.

Modular Thinking in Technology

Functions

In programming, a function is the most basic module. It takes inputs, does one thing, and returns an output.

Non-modular approach:
  Write one giant block of code that does everything.
  Need to change the tax calculation? Find it buried
  in 500 lines of mixed logic. Hope you do not break
  anything else.

Modular approach:
  calculate_subtotal(items)     -> returns subtotal
  calculate_tax(subtotal, rate) -> returns tax amount
  calculate_shipping(weight)    -> returns shipping cost
  calculate_total(subtotal, tax, shipping) -> returns total

  Need to change tax calculation? Modify one function.
  Need to add a discount? Add one new function.
  Need to reuse tax calculation elsewhere? Just call it.

Components in User Interfaces

Modern user interfaces are built from reusable components. A "button" component is used throughout an application. A "user profile card" component appears on every page that shows a user. A "search bar" component is used wherever search is needed.

UI Components (modules):
  - Button (label, color, click action)
  - Text input (placeholder, validation rules)
  - User card (name, photo, role)
  - Navigation bar (links, active state)
  - Modal dialog (title, content, actions)

Page assembly:
  Settings page = Navigation bar + Form (Text inputs + Buttons)
  User directory = Navigation bar + Grid of User cards + Search bar
  Dashboard = Navigation bar + Charts + Modal dialogs

Change the Button style once, it updates everywhere.
Build a new page by combining existing components.

Libraries & Packages

Software libraries are modules that entire applications can use. Instead of writing code to send emails, parse dates, or encrypt data, developers use existing libraries that do those things.

Building an application:
  Need to send emails?      -> Use an email library
  Need to process payments? -> Use a payment library
  Need to resize images?    -> Use an image library
  Need to generate PDFs?    -> Use a PDF library

  Each library is a module: clear inputs, clear outputs,
  standard interface, internal details hidden.

  The email library does not care what your app does.
  Your app does not care how the email library works internally.

APIs as Modules

An API (Application Programming Interface) turns an entire service into a module. Want weather data? Call a weather API. Want to process a payment? Call a payment API. Want to send a text message? Call a messaging API.

API-based architecture:
  Your application
    |
    |-- Weather API (input: location -> output: forecast)
    |-- Maps API (input: addresses -> output: directions)
    |-- Payment API (input: card details -> output: confirmation)
    |-- Email API (input: message -> output: delivery status)

  Each API is a self-contained module.
  You can switch from one maps provider to another
  without rewriting your entire application.

Designing for Modularity

Whether you are organizing a kitchen, building a business process, or writing software, the principles of good modular design are the same.

Single Responsibility

Each module should do one thing well. A module that does too many things is hard to reuse because you cannot use just the part you need.

Bad: A module that calculates tax, formats receipts,
     and sends emails. You cannot reuse the tax calculation
     without also getting receipt formatting and email sending.

Good: Three separate modules.
     Tax calculator. Receipt formatter. Email sender.
     Use any combination as needed.

Clear Interfaces

Define what goes in and what comes out. Everything else is internal and should not matter to the outside world.

Loose Coupling

Modules should depend on each other as little as possible. If changing module A requires changing module B, they are too tightly connected.

High Cohesion

Everything inside a module should be closely related. If a module contains unrelated functionality, it should probably be split into multiple modules.

Benefits of Modular Thinking

Benefit              Everyday Example                Tech Example
-------------------  ----------------------------    --------------------------
Reuse                Same recipe base, many meals    Same function, many features
Replaceability       Swap IKEA door styles           Swap email providers via API
Parallel work        Each person decorates one room  Each team builds one service
Easier debugging     Test one appliance at a time    Test one module at a time
Incremental change   Update one piece at a time      Deploy one service at a time
Reduced complexity   Focus on one drawer at a time   Focus on one component

Common Pitfalls

Making modules too small

If every tiny operation is its own module, the overhead of connecting them outweighs the benefit. A function that adds two numbers does not need to be its own module. Use judgment about what level of granularity is useful.

Making modules too large

A module that does twenty things is not modular. It is a monolith with a label. If you cannot describe what a module does in one sentence, it probably does too much.

Ignoring the interface design

The interface is more important than the implementation. A brilliant module with a confusing interface will not be reused. A simple module with a clear interface will be used everywhere.

Premature modularity

Do not modularize before you understand the problem. If you create abstract, reusable modules before you know what you need, you will likely design the wrong interfaces. Build something that works first, then identify what should be modularized based on actual reuse patterns.

Assuming modularity eliminates coordination

Modular systems still require coordination at the interface level. Someone needs to define and maintain the standards that allow modules to connect. LEGO works because someone maintains the stud dimensions. APIs work because someone maintains the endpoint contracts.

Not documenting how modules connect

Individual modules may be well-understood, but if nobody documents how they fit together, new people cannot work with the system effectively. The "assembly instructions" are as important as the parts themselves.

Key Takeaways

  • Modular thinking means building with self-contained, reusable parts connected through standard interfaces. It applies to LEGO sets, IKEA kitchens, wardrobe capsules, cooking, and software alike.
  • The interface is more important than the implementation. Standardized connections are what make modules powerful and interchangeable.
  • Good modules follow single responsibility (do one thing well), have clear interfaces, are loosely coupled to other modules, and have high internal cohesion.
  • In technology, functions, UI components, libraries, and APIs are all forms of modules. They enable reuse, parallel development, and incremental change.
  • Do not modularize prematurely. Understand the problem first, then identify natural module boundaries based on actual reuse and independence patterns.
  • Modularity reduces complexity by letting you focus on one piece at a time, but it does not eliminate the need for coordination at the interface level.