Building Software From the Inside Out

The part of my home I really use the most: everything inside the walls.

In our first meeting, Daniel Piechota, the architect who would design the remodel of my home, explained his approach to architecture:

Design from the inside out.

This means that rather than starting with how the finished structure should appear, you first study the way a space is inhabited and used, and then design the structure and surfaces out.

Daniel is not alone in his thinking. For instance, Becci Taylor pointedly writes:

I would like the industry to remember that most buildings only exist for their occupants. People are part of the building system, so let’s design from their point of view.
Too often, buildings are designed from the external render inwards — a constraint that makes it difficult to produce the best buildings.

Software development faces a similar problem. Consider the prevailing MVC model:

Model • Controller • View • (User?)

In MVC, our users are excluded from software in more than name alone. But, look what happens when we turn MVC inside out:

User • View • Controller • Model

Our users are included, and inhabit the space our software creates.

There’s been plenty of discussion about how software has biases that steer its users’ tendencies and behaviors. For our users aren’t just using the interface surface; they are mostly using all of the code beneath: our classes, objects, functions, databases. Surely the internal organization a developer builds is reflected in the final interface.

Wouldn’t it be interesting to analyze a set of open source projects on Github to see how deep into the code base each project’s behavioral biases are reflected. Anyone? Anyone? Bueller?

Where Does the Interface Begin?

Continuing our familiar architecture analogy: just as when building a home, in software you can’t start by building the surfaces with which people interact; you have to start with the structure and work your way out to those surfaces.

But, you can still build those structures with your user in mind, and there are opportunities to experience the structure and design of your code as if you were a user.

Often in the development process, the first user interface we code and use ourselves some sort of API. As Matt Gemmell writes:

APIs are UX for developers.
API design is very much like user interface and user experience design. Your target audience has different needs and characteristics, but they’re still humans who are looking to get a job done.

(Yes, you should read his excellent guide to API design.)

In my experience, the process of building an API has major structural implications all the way into the data layer. This can even necessitate rewriting and restructuring of our code and data models, once the functionality that our software is intended to deliver is shown in clear relief.

It’s is not a bad thing. Our software is better for this reconsideration: we gain clarity and insight into our design assumptions and expose possible inefficiencies or structural weakenesses.

An Example

Recently I was considering the operating states for Circopt, my still-in-very-early-development recirculating hot water controller. In the first version of my code, I grouped all of its states into one basket: run, delay, wait, and calibrate.

How I interacted with Circopt in the before times.

It worked and my home was happier.

Then I took a detour to build Porter, an app that gives you instant UI for Particle.

How I interact with Circopt now.

After coming back and using Circopt through the UI that Porter built from its API, I saw that those states was not actually how Circopt worked. As a user I would either want the system to be operating, controlling my pump, or calibrating, learning about the properties of the pump and recirculation loop.

Digging into my code, I realized that I had actually bundled a bunch of states into the “calibrate” state. Thus, Circopt not only has states, it has modes that contain a series of states. The operating mode would cycle through a series of states—run, delay, and wait—while the calibrate mode would cycle through its own unique series of states.

The Benefits of Early Exposure

The insights provided by an early interface is one of the exciting opportunities that Porter provides: it’s a tool that not only takes care of UI during development, but helps developers consider how their users will interact with their devices early in their process.

Since Porter automatically turns the device API you expose through the Particle Cloud into a user interface, you have immediate feedback on the utility of the organization and functionality of your code as an end user of your device.

So, this is the behavioral bias built into Porter: consider the end user early and often, develop from the inside out, and ensure that our increasingly connected physical environment is humanely working with us.

❖ I’d love to hear from you. Comment below or find me on Twitter. Let’s continue this conversation.

❖ I think Porter can help a lot of people go further and faster with their IoT ideas. But getting the word out is hard, so if you can help with a like or sharing, I’d appreciate it.

Porter is produced by Bright/Contrast LLC. Particle and Particle Cloud are trademarks of Spark Labs, Inc.