Interface Driven Design

There are infinite ways to think about code you want to write, but generally, they fall into two broad categories: code first or specification first. Suppose you wanted to make an inventory module to help you manage inventory items. "Code First" means you try to write your code top to bottom, predicting how you will use it later. In contrast, "Specification first" means you first decide what your requirements are.

Interface Driven Design (IDD for short) is one way to define requirements. It is a very easy principle: You call functions and properties that don't exist. That's it!

Of course, that means your program is full of errors and can't run. Once you are satisfied with how you use your API, you can start implementing it.

It's called "interface driven design" because the interest is in defining the ways your functions or classes are used. We also say that this is how they "interface" with the external world.

Why code first?

There are a few key benefits of API-First design:

Firstly, it helps not do more than necessary. As programmers, we're often anxious about potential future needs, and to cater to those imaginary needs, we often write code that is much more complex than it needs to be. This increases potential bugs and makes our code more difficult to read and maintain. It's also wasted effort.

Secondly, it helps to write code that we can actually use in the best way. When trying to predict how the code will be used in the future, you will often miss a large part of context and get it at least a little bit wrong. By using the code first, you ensure that its external API matches the needs. All guesswork is avoided in favor of answering actual proven needs.

In a team, it also means developers who use a feature and developers who implement a feature can work in parallel, without waiting on each other.

Once there are no errors anymore, the software is ready!

What are some other API-First methods?

The most used and known is Test Driven Design. While not exactly the same, TDD also involves writing code that uses functions or classes that don't exist yet. Developers start by writing tests for the desired functionality before implementing the actual code. This solves a number of similar problems to IDD, but does not keep the code small. It's too easy to write tests for hypothetical functionality and have more code than necessary.