Interface First Design

I first wrote about Interface First Design on [[2020-10-20]]. That was before I read these notes on [[A Philosophy of Software Design]]

Interface First Design: Design the interface of a program before you do any other work.

[[A Philosophy of Software Design]] has great vocabulary for the two phases of programming

• [[Tactial Programming]]: Get something to work
• [[Strategic Programming]]: Design good interfaces

Interface First Design is when you do [[Strategic Programming]] before [[Tactical Programming]].

Developers, especially new developers, are quick to jump to the tactical phase. It feels like the faster path to the end. In school, it often works because the api doesn't really matter, because you only use it a few times before you ditch it for the next assignment. However, software that makes money requires continuous maintanence and improvements. Lack of effort on the strategic phase leads to bad design, frustration, and wasted time.

[[John Ousterhout]] supports this claim, writing "payoff for good design comes quickly. It's unlikely that the tactical approach is faster even for the first version, let alone the second."

Strategic Phase

The output from the strategic phase is a mocked api that you fill in with implementation during the tactical phase. I give a concrete example on [[2020-10-20]].

The strategic phase is for people. This code is for you, not the computer - cut the computer out of the question. The output of strategic programming is for you to understand your interfaces and where it's best to hide complexity. It is a mistake to think hard about running code in this phase. At first, this may feel wasteful, but as you spend more time in this phase, you begin to appreciate the extra focus you put into design.

My current stance is that you should spend time on the strategic phase for every single project, no matter how big or small. In the worst case scenario, which is the implementation is not possible, you are still left with the mocked api as a note for you and future developers to return to and quickly grasp the original goal.

Tactical Programming

This is the bread and butter of programming. The tactical phase is when you lock in and bend the computer to your will, which is what makes it so tempting to jump right in. It's important to remember that the end of the tactical phase is much more satisfying when you already have an goal in mind - the mocked api you created in the strategic phase. Without the end goal, you often end up with a fragile Frankenstein api you can barely use. I've fallen victim to this many times... pretty much any code assignment I did in college.

Also, when stuck on a tactical problem, it's often helpful to switch back to strategic mode to ensure the problem you face is necessary for your goal.

Good Interfaces

Lastly, what is a good interface? It is one that manages complexity by hiding it in implementation. From [[A Philosophy of Software Design]]:

• "The most important way to manage complexity is by shifting it from interfaces and into implementation"

Extensions

This idea extends to other realms as well. Before jumping into the tactical details of any problem, you should establish a clear goal. Without that goal, you end up with a smorgasbord of information that's difficult to put together. Or, you are forced into the strategic phase after the fact, when you realize you wasted a lot of time focusing on the wrong information. For any project, make sure to start strategic before moving to tactical, and continuously alternate between the two until you've reached your goal.

My Linked Notes

• brain
  
  • [[Interface First Design]]
• 2020-10-20
  
  • One switch has improved my programming more than anything else: [[Interface First Design]].
• 2020-10-25
  
  • [[interface first design]]. [[Begin with the end in mind]] design [[2020-10-20]]
• 2020-10-28
  

  On [[2020-10-20]], I wrote about [[Interface First Design]]. If books are software packages, then they are meant to provide specific functionality as part of a larger system. Like software, instead of building that functionality from scratch, we leverage the hard work of the author.
  If this analogy holds, then [[interface first design]] applies to books as well. Before, reading another book, spend 15 minutes designing an "api" new learnings from the book will build.

• 2020-10-28
  

  On [[2020-10-20]], I wrote about [[Interface First Design]]. If books are software packages, then they are meant to provide specific functionality as part of a larger system. Like software, instead of building that functionality from scratch, we leverage the hard work of the author.
  If this analogy holds, then [[interface first design]] applies to books as well. Before, reading another book, spend 15 minutes designing an "api" new learnings from the book will build.

• 2021-02-14
  

  Welcome back (or for the first time) to the Weekly Review! This week I updated some notes on [[Interface First Design]], give an update on the [[Voice Memo Experiment]]'s success, ramble about the [[Dweb]], and talk about a crazy new thing I found. Hope you enjoy!

• 2021-02-14
  

  [[Interface First Design]]

• 2021-02-14
  

  The Jungle hit a big milestone this week: a complete stranger reached out about writing on this site! He recently read A Philosophy of Software Design and found my notes on [[Interface First Design]] interesting because of similar ideas from the book. I was excited, then I looked at my notes on the page itself. There were none! And the linked notes were a mess. I commend the stranger for persevering through my mess to get to the good stuff, and I really appreciate him reaching out.

• 2021-02-14
  

  I updated the [[Interface First Design]] page with new ideas from the book. Check it out!

• trailheads
  
  • [[Interface First Design]]

One last thing

If you liked these notes, hit me on Twitter!