State — DRAFT, but ready for feedback. Some sections feel incomplete, and there’s no conclusion.
As software developers, we make decisions all day. How do I approach this problem? How do I start carving off its unknown pieces? How can I know where to direct my attention?
I’ve found that most of my effort as a software developer can be reduced to:
Alternative title: Multiscale design. Why? We’re really just making design explicit through the stack. Is that a better title? I don’t really think so. It’s a bit vague.
Curious? Read on.
The most important thing I’ve learned about software development in the last three years is to take feedback loops and interface design seriously. I feel like I unlocked something. I don’t get stuck the same way I used to get stuck. Thinking back, I used to throw brainpower at a problem. Thinking that thinking would solve all the problems. A common failure mode of mine was getting stuck in my head when the problem was too big to fit.
That can simply happen when all there is is implementation. There’s nothing else.
What can we do differently?
We achieve seeing better by improving our feedback loop. We reduce the problem to smaller pieces by designing interfaces.
“Then, should I focus on feedback, interface or implementation right now?”
That’s a matter of taste!
But thinking about it, I definitely have a preference.
If you don’t have any feedback loop, make sure you have a feedback loop. If your feedback loop sucks (>1 second), fix it. (or at least try, working without a good feedback loop sucks)
Depending on your environment, that feedback loop could run tests, print stuff or whether your types line up. You should be able to introduce an error, watch your feedback loop “go red”, fix the error and go back to green.
Now that you have a feedback loop up and running, good! Interface comes next. We’re trying to achieve something. For now, let’s only consider the what. Anything we can do to ignore the how is good. In typed programming languages, let’s consider types. Are we transforming something? From a type to another? What are those types? Do we need to write some types? I often like to write the types of functions before I even name the function.
In data-oriented languages, we’ll want to consider some example data. What are we transforming to what?
And in any case, we’ll probably want to use unit tests. The unit tests are going to describe what’s actually going to happen. While we can peek at some data, the unit tests don’t require peeking at all. They have correct/incorrect encoded into the core. That means the computer can help us find out which part of the system is failing. So we prefer unit tests over eyeballing and examples.
In all these cases, we want to take our interface design (be it interfaces or data models or tests) very seriously. We can completely avoid big chunks of problems by picking the right type or data model. “How seriously, in time?” Depends 😬 But perhaps 1/3 feedback system, 1/3 interface design and 1/3 implementation? Please don’t take this as dogma. Try to feel your way forward. Experiment. Note that we don’t spend the first hour on feedback, the next on interface and the third on implementation! We jump back and forth.
Finally! We have our feedback loop. We can ask it “does it work now?” (feedback) And we have defined what “correct” means (interface design) Now, get cracking! Walk a step forwards, see the unit tests go green. Celebrate! 🎉
| Author | Software developer today |
| Consumer | Software developers later |
You’re going to do the work. But what do your increments look like? How do you know that an increment works? Letting you know whether / how your increments work is the job of your feedback loop. You’re going to be checking your feedback loop frequently as you work. I prefer very often. Every ten seconds of more often. Probably bound to some on-save action.
The thing you’re making. How is it going to be used? What do you provide? A module with a public interface? A REST endpoint? Will your thing be nice to use?
When you’re working on interface design, it’s your job to ensure that the things you’re making are nice to use.
With a good feedback loop and solid interface design, implementation is often the easy part. A good feedback loop lets you know whether / how your thing works at every point in time. And good interface design will split your problem into reasonable parts. If implementation is hard, consider splitting your problem. Splitting your problem is introducing an interface. So do a bit of interface design, then come back. And ensure that your interface is easy to test — this means you’ll get value out of your feedback loop!
| Author | Product designer |
| Consumer | End-user |
How long is the cycle time from changing product behavior to seeing how the new behavior performs? How wide is the product feedback that we’re getting? High-resolution feedback is being inside the user’s head while they solve a complete product “job to be done”. Low-resolution feedback is asking the users what they think once in a while.
Does the user understand how to use the product? How long does it take a new user to get up to speed? How effectively can a user solve common tasks? Where is the friction? Are jobs to be done easier to get done with your product than with options? What are the best jobs to be done?
Challenge: many features.
How do we perpetually add value without ending up in “buttons everywhere hell”?
Challenge: uncertainty.
How do we know what to make when we don’t really know before we’re there — and we might not have a return ticket?
DRAFT
| Author | Innovator |
| Consumer | Industry |
Finally, the top level. Let’s recap.
Level 1 - software view. The interface is the module interface. Feedback is how easy it is to work with modules.
Level 2 - product view. The interface is the product texture. Feedback is how smooth it is to execute a workflow.
Makes sense? Now, let’s introduce the birds-eye view.
Level 3 - industry view. The interface is current market best practices. Feedback is how effectively the workflows can compete with other workflows. Are you enabling better workflows?
| Feedback loop | How do we know if it works? How does it feel? |
| Interface design | How should it work? How should it feel? |
| How it works | Let’s bridge the current behavior to correct behavior. |
The article is over!
Right now, I’ve split the article into sections about feedback loop, interface design and implementation. That’s clear. However, the lines get kinda … blurred sometimes. Take the trailing part of the section about implementation in software development:
With a good feedback loop and solid interface design, implementation is often the easy part. A good feedback loop lets you know whether / how your thing works at every point in time. And good interface design will split your problem into reasonable parts. If implementation is hard, consider splitting your problem. Splitting your problem is introducing an interface. So do a bit of interface design, then come back. And ensure that your interface is easy to test — this means you’ll get value out of your feedback loop!
Would it be better to separate between definitions (what feedback/interface/implementation means in a context) and case-based discussion? 🤔
npx live-serverSource: https://prog21.dadgum.com/56.html
it’s tighter. and interface/internals is a stronger contrast than “interface design” and “how stuff works”.
also, “interface design” – the feedback loop must be desinged, the internals must be designed. also, “how stuff works” is super vague and should be avoided.