The 42 Principles · Principle XXVI

Build Small. Think Big.

Incremental progress, bounded experiments, reversibility, learning quickly, and scaling only after understanding.

Foundational Truth

Large outcomes do not always begin with large ideas.

Sometimes the smallest change reorganizes everything around it.

A vacuum tube becomes a transistor.

A glowing filament becomes a light-emitting diode.

An analog signal becomes digital information.

Each transition began at a scale small enough to overlook.

Yet each one changed what humanity could build.

Smaller components made machines faster.

More efficient.

More reliable.

More portable.

More affordable.

Eventually, those small changes reshaped communication, medicine, transportation, science, entertainment, and daily life.

The size of an idea does not determine the size of its consequence.


Small Changes Rebuild the World

The transistor did not resemble a revolution.

It was a small device replacing a larger one.

But that smaller device consumed less power, generated less heat, failed less frequently, and could be manufactured at extraordinary scale.

One improvement enabled another.

Smaller components allowed smaller circuits.

Smaller circuits enabled more complex machines.

More complex machines became general-purpose computers.

Computers became networks.

Networks became the digital world.

The transformation did not begin with one impossibly large machine.

It began by making one essential component smaller and better.

The same pattern appears repeatedly.

Incandescent bulbs produced light by heating a filament until it glowed.

LEDs produced light through a far more efficient physical process.

The immediate change was the light source.

The broader consequences included longer service life, lower energy consumption, smaller devices, reduced heat, new display technologies, and lighting in places where traditional bulbs were impractical.

Small improvements create new possibilities because they remove constraints.


The Power of a Compact Idea

Some ideas are powerful not because they explain everything, but because they reveal a relationship so fundamental that entire fields can build upon it.

Einstein's mass-energy relation is remembered through one of the shortest equations in science:

E = mc²

Its strength comes from compression.

A small expression captures an idea with consequences far beyond its length.

That is what elegant engineering often does.

It identifies the right relationship, defines it clearly, and allows larger systems to emerge from it.

A powerful design does not need to be large. It needs to be fundamental.


Build from Composable Parts

Software should follow the same principle.

A small function is easier to understand.

A small service is easier to test.

A small interface is easier to document.

A small component is easier to replace.

When those pieces have clear responsibilities and predictable boundaries, they can be composed into systems far larger than any one piece.

Build small enough to understand. Think big enough to compose.


Security Is Measured by Effectiveness

It is possible to create an architecture with firewalls behind firewalls, NAT behind NAT, multiple DMZs, honeypots, proxies, overlapping inspection systems, and dozens of security products.

It may look impressive.

It may also become impossible to operate.

Every additional layer must be configured, monitored, patched, documented, tested, and understood.

Complexity alone does not create security.

Strong authentication.

Least privilege.

Current patching.

Clear segmentation.

Useful logging.

Tested recovery.

Applied consistently, these often provide greater value than adding another layer that few people understand.

The objective is not fewer controls.

The objective is better controls.


Small Does Not Mean Shortsighted

Build each component with one clear responsibility.

Understand how it fits into the larger vision.

Keep the implementation small.

Keep the ambition large.


Closing Thought

History is filled with small discoveries that removed large constraints.

Do not confuse scale with significance.

Build pieces people can understand.

Connect them with intention.

Let their combined value become greater than any individual component.

Build small enough to remain clear. Think big enough to change what becomes possible.

The Power of Composition

Every great system is built from smaller systems.

A computer is not one invention.

It is millions—or billions—of transistors working together.

The Internet is not one network.

It is thousands of independently managed networks agreeing on common standards.

A skyscraper is not one beam.

It is thousands of carefully engineered components sharing the load.

Nature follows the same pattern.

Cells become tissues.

Tissues become organs.

Organs become living organisms.

Small parts.

Large purpose.

The lesson is remarkably consistent.

The greatest systems are rarely created by making one thing enormous.

They are created by making many small things dependable.

Scale is achieved through composition, not accumulation.


The Myth of Bigger

Engineers are often tempted to solve problems by adding more.

Another firewall.

Another monitoring tool.

Another middleware layer.

Another proxy.

Another framework.

Another abstraction.

Another service.

Sometimes another layer is exactly what the system needs.

Often it is not.

Every new layer increases the number of interactions.

Every interaction increases the number of possible failure modes.

Every failure mode creates another troubleshooting path.

The architecture becomes harder to understand.

Harder to explain.

Harder to secure.

Harder to recover.

Large systems do not fail because they are large.

They fail because nobody fully understands how all of the pieces interact.

Growth without clarity eventually becomes fragility.


Simplicity Creates Leverage

One elegant function can eliminate hundreds of repeated lines of code.

One well-designed API can support dozens of applications.

One authentication platform can secure an entire organization.

One deployment pipeline can standardize hundreds of releases.

The impact of these solutions is far greater than their physical size.

That is leverage.

Leverage occurs when a small improvement is reused repeatedly.

The engineer who automates one deployment does not save five minutes.

They save five minutes every time the deployment occurs.

The engineer who simplifies authentication does not improve one login.

They improve every login.

The value compounds.

Small improvements become organizational advantages.


Design for Growth

Small components should never be designed with small ambitions.

A reusable module may begin supporting one application.

Tomorrow it may support fifty.

An API built for one customer may eventually serve thousands.

A script written to solve one problem may become the organization's standard.

Thinking big means asking:

  • What happens if this succeeds beyond my expectations?
  • Will this component still make sense?
  • Will people understand it?
  • Can it evolve?
  • Can it be replaced?
  • Can it be tested independently?
  • Can it fail without bringing everything else down?

Thinking big is not about predicting the future perfectly.

It is about leaving room for the future to happen.


Resist Cleverness

Some engineers build systems to impress other engineers.

The code becomes clever.

The architecture becomes intricate.

The solution becomes difficult to explain.

Complexity begins masquerading as intelligence.

The strongest engineers usually move in the opposite direction.

They simplify.

They remove.

They clarify.

Anyone can add another layer.

It takes discipline to remove one.

An elegant design often appears obvious in hindsight.

That is not because it was easy.

It is because someone worked very hard to eliminate everything unnecessary.

If your architecture requires a lengthy explanation, the design may not yet be finished.


Build Foundations, Not Monuments

Large systems eventually change.

Requirements evolve.

Businesses merge.

Technologies improve.

Teams grow.

Architectures built around enormous, rigid components struggle to adapt.

Architectures built from clear, dependable building blocks evolve naturally.

The goal is not to predict every future requirement.

The goal is to build foundations strong enough to support requirements you have not yet imagined.


Closing Thought

The world remembers remarkable outcomes.

Engineers should remember the small decisions that made those outcomes possible.

History is rarely changed by making one thing larger.

It is changed by making one important thing better.

Build components that are small enough to perfect, and visions that are large enough to inspire.

The Principle Is Universal

The greatest transformations in history rarely arrived all at once.

They emerged from a single improvement repeated until it reshaped the world.

One improved farming technique fed villages.

One printing press spread knowledge across continents.

One steam engine changed manufacturing.

One transistor launched the digital age.

One reliable shipping container transformed global commerce.

Each began as an improvement to something much smaller than the final outcome.

The lesson is timeless.

Lasting change is usually built one dependable improvement at a time.

History is not built by giant leaps alone. It is built by countless small steps moving in the same direction.


Excellence Compounds

People often underestimate the power of small improvements because they judge them in isolation.

Saving one minute appears insignificant.

Reducing one defect seems trivial.

Removing one unnecessary dependency feels unimportant.

Improving one process appears invisible.

But systems are not experienced once.

They are experienced repeatedly.

A one-minute improvement performed a thousand times becomes days.

One prevented mistake repeated across an organization becomes thousands of dollars.

One simplified process adopted by hundreds of engineers becomes an entirely different company.

Excellence compounds.

Not because any single improvement is extraordinary.

Because small improvements rarely remain alone.


Build for the Next Engineer

Every component you build teaches the next engineer something.

Clean interfaces teach clarity.

Good documentation teaches ownership.

Simple architecture teaches discipline.

Predictable behavior teaches trust.

The next engineer should not need to admire your intelligence.

They should appreciate your restraint.

The greatest compliment to a system is often this:

"I understood it immediately."

That is not accidental.

That is craftsmanship.


Big Thinking Requires Humility

Thinking big does not mean believing your first design is perfect.

It means accepting that your work may eventually become part of something much larger than yourself.

Your script may become a platform.

Your utility may become a company standard.

Your API may support customers you have never met.

Your documentation may teach engineers you will never know.

That possibility should encourage humility.

Not ego.

Build so others can extend your work.

Not admire how difficult it is to understand.


The Legacy of Small Decisions

Architects often remember the large projects.

History remembers the small decisions that made those projects possible.

The naming convention that eliminated confusion.

The reusable library that prevented duplication.

The deployment script that removed human error.

The authentication model that protected thousands of accounts.

The logging standard that solved an outage in minutes instead of days.

Those decisions rarely make headlines.

They quietly become the foundation upon which everything else is built.


Questions to Ask Yourself

  • Can this be made simpler without losing capability?
  • Does this component have one clear purpose?
  • Will someone understand this five years from now?
  • Does every layer add measurable value?
  • Am I optimizing for elegance or complexity?
  • If this succeeds beyond expectations, will it still scale?
  • Am I building something impressive, or something useful?

Closing Thought

Never underestimate the influence of a well-designed small thing.

History repeatedly shows that the greatest revolutions begin with improvements that almost nobody noticed at first.

Build what is small enough to perfect, and meaningful enough to outlive you.

Founder's Commentary

Small Ideas Built My Career

When I look back over my career, I don't remember one defining moment where everything suddenly changed.

I remember hundreds of small improvements.

One PowerShell script that removed a repetitive task.

One deployment that became predictable.

One monitoring rule that detected failures before customers noticed them.

One naming convention that eliminated confusion.

One piece of documentation that prevented the same mistake from happening twice.

None of those felt revolutionary when I created them.

Looking back, they changed everything.

Engineers sometimes dream about building the next great platform.

There is nothing wrong with that.

But most great platforms begin exactly the same way.

Someone solves one problem exceptionally well.

Then another.

Then another.

Eventually those small solutions begin connecting together.

People call it innovation.

The engineer remembers it as Tuesday.

Over the years I have inherited systems that seemed incredibly sophisticated.

Some contained dozens of frameworks.

Hundreds of integrations.

Thousands of configuration settings.

Yet they were fragile because nobody truly understood them.

I've also inherited remarkably simple systems.

They weren't exciting.

They weren't fashionable.

But they were dependable.

Those systems kept businesses running while everyone else chased the next trend.

That taught me something I have never forgotten.

Sophistication is not measured by complexity.

It is measured by clarity.

I would rather inherit one thousand lines of code that everyone understands than one hundred lines that only the original author can explain.

I would rather support ten dependable services than one brilliant system that nobody dares to change.

Small pieces give organizations confidence.

Confidence allows organizations to grow.

Growth creates opportunities no one could have predicted when the first component was written.

That is why I believe this Principle applies far beyond software.

The strongest relationships are built one conversation at a time.

The strongest companies are built one customer at a time.

The strongest reputations are built one decision at a time.

The strongest engineers are built one lesson at a time.

Nothing truly remarkable begins fully grown.

Everything begins with one small decision made well.

If there is one lesson I hope future engineers remember, it is this:

Never underestimate what one well-designed idea can become.

The world is rarely changed by one enormous breakthrough. It is changed by thousands of small decisions made with extraordinary care.


Related Principles

Continue the idea.

These Principles share themes with Principle XXVI.