Writing Software From the Top-Down

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:
- Bottom-up - determine the technical requirements first; then, build an experience around that framework
- 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.