Writing Software From the Top-Down

Computer code next to plant

I came across this article that I wrote a few years back and enjoyed reading it again so I thought I would throw it up here on my new site. If you have an opinion, I’d love to hear it!

After a few years of writing software, I’ve settled on one thought process for planning what I create. Whether I’m building a customer facing feature or a command-line utility, I start by thinking about the end-user experience.

There are two angles to take when writing software:

  1. Bottom-up - determine the technical requirements first; then, build an experience around that framework
  2. Top-down - plan the experience assuming anything is possible and consider the low-level details afterwards

The Bottom-up Thinking Trap

When I’m planning something out, it’s easy to fall into the trap of bottom up thinking. My first inclination as a programmer is to figure out all of the details of what I’m going to implement and write them down. I might ask myself several questions:

  • Do I need a new data model for this feature?
  • Do I need to manipulate any existing data models in new ways?
  • Is what I’m trying to accomplish feasible on a large data set?

Starting with this type of thinking is a trap. Once I’ve finished putting up constraints based on technical limitations, what I’m left to work with is much less creative.

Consider the following approach:

The Top-down Approach

I assume anything is possible. I talk to friends, colleagues, and strangers and ask what kind of experience they would expect. I draw out the flow of the feature on paper. I mockup and animate the feature and ask for more feedback then iterate.

Once I’ve nailed down the final experience, I figure out what it takes to make it work. This might be much more difficult and I might need to make some compromises, but the end result is much more satisfying.

Final Thoughts

Maybe this is obvious to others but I often fall into the trap of bottom-up thinking. I find myself writing software and thinking about the requirements first, then building an experience around that. Whenever I notice myself thinking this way, I flip it upside down.

Whether I’m building a shed, writing a new feature for a web product, or planning a trip, I take the top-down approach when creating something great.