Bottom-Up, Top-Down: Why I Build Both Ways at Once

“I’ll go start on the code before I even have a strategy.”

I said that about myself on a working call this year, and it describes how I build things dead accurately. Give me a problem and my hands are on the keyboard before my head has decided what the finished product is supposed to do. I love that part of the work. It has also cost me rework, and I hate rework.

So I’ve changed. What I do now is a hybrid: I go bottom-up and top-down at the same time, and it works. Either one by itself fails, and I’m done pretending one of them is enough.

On the Greek island of Samos, in the sixth century BC, an engineer named Eupalinos had a water tunnel cut through a mountain from both sides at once. Two crews with picks, chisels and hammers dug toward each other through a little over a kilometer of rock. Somebody had to work out from above where both holes had to go, and somebody else had to swing the pick in the dark.

When the crews broke through, the floors were off by about 60 centimeters. Near the meeting point the tunnel zigzags, and historians still argue over whether that was the plan or a run of corrections by crews who could hear each other through the rock. I want my software and my books built like that tunnel.

What is the difference between bottom-up and top-down development?

Top-down starts with the goal and breaks it into smaller pieces until each one is small enough to build. Bottom-up starts with pieces you can build today and assembles them upward until something useful appears.

Niklaus Wirth put the top-down method on paper in 1971, in an article called “Program Development by Stepwise Refinement.” You state the whole program as one instruction and refine it into a few. Each of those gets refined again, and you keep going until every line is something a computer can run.

Bottom-up is how most programmers learn, whether anybody admits it or not. You write a routine that works, then another one, and then you glue them together and see what you’ve got. Books follow the same split. A top-down author writes the outline first and fills it in. A bottom-up author writes the stories and scenes that are burning to get out and assembles a book from the pile.

Each method has a strength the other lacks. The top gives you direction, and the bottom gives you something that works.

Watch: Brains@Work - Top-Down vs. Bottom-Up | The Mechanics of Decision Making, Arne van Oosterom

I’ve been a bottom-up builder since my first job

I left college early when a teacher offered me a job. I started as a coder, then became a manager, then a VP. In those early years I was coding whole accounting packages in assembly language, where you tell the machine to load register one, load register two, and you get down to the nitty gritty of every single step. Most people go insane doing that stuff. For me it was easy.

Assembly trains your brain to work from the bottom. You can’t write a general ledger until you can add two numbers, store the result and get it back, so you build the small reliable pieces first and trust them. That habit never left me, and thirty-three years in enterprise technology didn’t knock it out.

Today the habit shows up in WordPress.

I’ve built 90+ custom plugins for this site with Claude’s help. Claude can write a plugin in minutes: I say, write me a plugin that does this, and the code shows up. The debugging comes after.

My booking plugin took a couple of hours to write and went through 44 versions. A bug in one of those versions lost bookings without a word of warning, and nobody caught it until Joe Rockey tested it live on a call with me. Forty-four versions! I’m proud of that plugin and annoyed by that number in the same breath.

My AEO plugin followed the same road. I wrote all of it first and audited it afterward. The security audit found a couple of security problems, and the performance audit found a big performance problem. Now it’s really cool, and I had a blast building it. The order was still backward.

Why does bottom-up development fail without a strategy?

It fails because without the top you end up making a bunch of parts you’ll never use. Every part works. Nothing fits.

Bottom-up feels productive every minute of the day, and that’s the trap. You finish a function, it runs, you get the little hit of satisfaction, and you go build the next one.

Three weeks later you try to connect the pieces. Two of them assume different things about the data, one solves a problem nobody has, and the feature the project needed most doesn’t exist because it was never anyone’s next small piece. Then you rip things out and rebuild them. Rewrites burn time, money and effort, and going back to a client over a change in scope is miserable for everybody. I hate it.

The top also asks questions the bottom never thinks of. When I explain Windows scheduled tasks to people, I tell them the worst thing that happens, unless you’re doing mass deletes, is that a task doesn’t run and doesn’t tell you. A builder working from the bottom never asks that, because each task works fine on the day he writes it. You only see the danger from above. The fix is a top-level piece: another scheduled task, once a day, that checks the last date each job ran and complains when one goes silent.

Software teams with no strategy produce dashboards nobody opens and code nobody can explain a year later. The waste lands on the people who have to maintain it long after the builders have moved on, and I think that’s a lousy thing to do to them.

Top-down alone fails too

Unfortunately, the cure most organizations reach for is pure top-down, and it fails just as hard in the other direction.

A plan written entirely from above is a guess about problems nobody has met yet. You don’t find out which parts are hard until you try to build them, and by then the plan has been approved, printed and defended in three meetings.

The consultant who delivered the strategy deck has cashed the check and left. The executive who signed it can’t afford to be wrong. So the team builds the plan as written, discovers halfway through that it doesn’t work, and spends the next year bending reality to fit a document. I can’t stand that kind of arrogance, and I’ve written about how it sinks companies in why digital transformations fail.

A top that can’t change is worse than no top at all.

Early in a book project I tell clients not to be surprised if the audience changes a little as we talk, because changing it costs nothing before the writing starts. The early outline doesn’t need to be tied down, either. We have time to change it. A strategy is a hypothesis, and the bottom is where you test it.

How do you work bottom-up and top-down at the same time?

You write the top first, in one page, and you start building small working pieces the same day. The bottom never runs a day without being held against that page.

That page answers a few blunt questions. What will the finished product do, and for whom? What does done look like? What must never happen? That last question is the one people skip, and it’s the one that would have told me to put a watchdog on my scheduled tasks before the first one died in silence. Keep it to a page. If the strategy needs forty pages to explain, nobody will read it, including you.

Next, build the thinnest possible version of the product, end to end.

Andrew Hunt and David Thomas called this tracer bullets in The Pragmatic Programmer back in 1999. You make a crude path through every layer that works, so you can see whether you’re aimed at the target before you build any layer properly. A tracer bullet is bottom-up code doing top-down work. It proves the plan, or it embarrasses the plan early, while changing course is still cheap.

Every working session after that has two moves. Build the next piece, then hold it against the page. Does this piece serve something on the page? If not, why am I building it?

When the bottom teaches you something the top got wrong, and it will, change the top on purpose and write the change down. Don’t let the code drift away from the plan until nobody knows which one is true. Schedule an audit at the close of each phase, because security and performance problems are cheap in week two and expensive in month six. Most teams get software testing wrong in exactly that way.

Two crews, one survey. Check the survey every day.

What does a book outline do for a ghostwriter?

The outline is the top of a book. Once the client approves it, it becomes the spec, and I write from it the way a programmer codes from a specification.

I build that top backwards. We start from the destination: what emotion the reader should feel when they close the book, then what they should do and what they should learn. I’ve laid out that whole process in how I outline a book. I’ll draft several outline formats from the same material, one by theme and one by chronology, and let the client pick the structure that fits.

I focus hard on the purpose and the audience before any of it, because if that part’s wrong we’ll go in the wrong direction. I do not want to get to chapter 10 and hear that this wasn’t our purpose at all.

Then the outline turns into the Bible. I tell clients to review it carefully and to mark changes in brackets, like code, so the tools can see them. Most clients don’t even look, even when I tell them flat out that it’s the spec and I won’t accept changes beyond minor ones after that.

It drives me nuts.

There’s more on what the outline does on a project in a separate piece. Think of it as the survey for the tunnel.

The bottom still moves inside a good outline

Before each chapter I send the client a page or two of bullet points for that chapter alone. They mark it up and I adjust it. The revised outline becomes my spec for writing the chapter. That’s top-down at the chapter level. The writing itself is bottom-up, and it pushes back.

On a recent book, Chapter 1 bled into Chapter 2 while I was writing it. The material had a natural split in it that the outline didn’t show, so I put the split where it belonged and went back to fill in what was missing between the cracks. The client didn’t object, because it was the same material, divided differently. A good outline survives that kind of correction from below.

A lot of my books start from the end. Once I know where the last chapter lands, everything before it has something to aim at.

I hold off on chapter two until the client approves the voice of chapter one, because I don’t want to get the first one wrong and redo the second. And I keep the last month of a project for comparing chapter against chapter. A first draft has repetition between chapters, and nobody can see it from inside a single chapter. Only the top can. We do the heavy thinking up front so the back end of the project stays calm, and the hybrid is how I get there.

Should a novelist outline first or write first?

Do both. My longest-running novel is proof.

Peacekeeper grew from one question: what happens when a 250-million-ton spaceship hits a planet at 99 percent of the speed of light? I calculated it online, and the answer was that every star within a hundred light years goes nova. I toned it down. That question was pure bottom-up, a single piece of physics that wouldn’t leave me alone.

I carried that book for 45 years. When I finally sat down to finish it, I threw the old draft away and started over, because it was all stupid writing I did back then.

The kernel survived. The villain stands right next to the hero through the whole book, and the hero never knows it until the end. Nobody plants a villain like that by writing scenes and hoping. Somebody has to know the ending and work backward from it, the same way I outline a client’s memoir, and every hint along the way has to be set up so a reader can see it in retrospect.

My own fiction habit is a hybrid I call the ink blot method. I have an idea and write the first chapter. Then I outline, then I write whatever chapters strike my fancy and connect them together.

That’s bottom-up and top-down taking turns in the same book.

Fiction writers love to argue about plotters versus pantsers as if they had to choose a team. I think it’s a silly fight. Your idea grabs you from the bottom, and the shape that makes readers finish the book comes down from the top.

Where the two crews meet

I’m still a bottom-up guy, and I don’t apologize for it. The code I write in the first hour teaches me things no strategy document ever could. What I won’t do anymore is dig blind.

A builder with no top produces parts nobody uses, a planner with no bottom produces a document nobody tested, and organizations pay through the nose for both. Damn it, the fix isn’t complicated. Write the top on one page, build small working pieces against it from the first day, and change the page on purpose when the rock tells you something.

If you’re planning a system, a transformation or a book, start both crews digging this week. More on the tools behind that work lives in the Technology of Writing Hub, and if you want somebody who has run both crews to look at your plan, see my digital transformation process. Eupalinos had a survey from above and picks in the dark, and his crews met under that mountain about 60 centimeters apart. Your project deserves that kind of aim.

Frequently Asked Questions