The Developer Feedback Loop

if you write software, the term “feedback loop” might have made its way into your vocabulary. it charts a slightly indirect route from its conception and into the developer lexicon, though, so let’s start with the term’s origin. a feedback loop in general systems uses its output as one of its inputs.

kind of vague, huh? i’ll clarify with an example. i’m actually writing this post from a hotel room, so i can see the air conditioner from my seat. charlotte, north carolina, my temporary home, boasts some pretty steamy weather this time of year, so i’m giving the machine a workout. its led display reads 70 fahrenheit and it’s cranking to make that happen.

when the ac unit hits exactly 70 degrees, as measured by its thermostat, it will take a break. however, as soon as the thermostat starts inching toward 71, it will turn itself back on and start working again. such is the sisyphean struggle of climate control.

important for us here, though, is the mechanics of this system. the ac unit alters the temperature in the room (its output). it also uses the temperature in the room as input (if < 71, do nothing, else cool the room). climate control in buildings operates via a feedback loop.

appropriating the term for software development

it takes a bit of a cognitive leap to think of your own tradecraft in terms of feedback loops. most likely, this happens because you become part of the system. most people find it harder to reason about things from within.

in software development, you complete the loop. you write code, the compiler builds it, the os runs it, you observe the result, and decide what to do to the code next. the output of that system becomes the input to drive the next round.

if you have heard the term before, you’ve probably also heard the term “tightening the feedback loop.” whether or not you’ve heard it, what people mean by this is reducing the cycle time of the aforementioned system.  people throwing that term around look to streamline the write, build, run, and write again process.

a history of developer feedback loops

at the risk of sounding like a grizzled old codger, let me digress for a moment to talk about feedback loop history. long before my time came the punched card era . without belaboring the point, i’ll say that this feedback loop would astound you, the modern software developer.

programmers would sit at key punch “kiosks” used to physically perforated forms (one mistake, and you’d start over). they would then take these forms and have operators turn them into cards, stacks of which they would hold onto. next, they’d wait in line to feed these cards into the machines, which acted as a runtime interpreter. often, they would have to wait up to 24 hours to see the output of what they had done.

can you imagine? write a bit of code, then wait for 24 hours to see if it worked. with a feedback loop this loose, you can bet that checking and rechecking steps received hyper-optimization.

when i went to college and started my programming career, these days had long passed. that doesn’t mean my early days didn’t involve a good bit of downtime. i can recall modifying c files in projects i worked, and then waiting up to an hour for the code to build and run, depending what i had changed. xkcd immortalized this issue nearly 10 years ago in one of its most popular comics.

today, you don’t see this as much, though certainly, you could find some legacy codebases or juggernauts that took a while to build. tooling, technique, modern hardware, and architectural approaches all combine to minimize this problem via tighter feedback loops.

the worst feedback loop

i have a hypothesis. i believe that a specific amount of time exists for each person that represents the absolute, least-optimal amount of time for work feedback. for me, it’s about 40 seconds.

if i make some changes to something and see immediate results, then great. beyond immediacy, my impatience kicks in. i stare at the thing, i tap impatiently, i might even hit it a little, knowing no good will come. however, after about 40 seconds, i simply switch my attention elsewhere.

now, if i know the wait time will be longer than 40 seconds, i may develop some plan. i might pipeline my work, or carve out some other tasks with which i can be productive while waiting. if, for instance, i can get feedback on something every 10 minutes, i’ll kick it off, do some household chores, and periodically check on it.

at 40 seconds, it resides in some kind of middle limbo, preventing any semblance of productivity. i kick it off and check twitter. 40 seconds turns into five minutes when someone posts a link to some cool astronomy site. i check back, forget what i did, and then remember. i try again and wait 40 seconds. this time, i look at a buzzfeed article and waste 10 minutes as that turns into four buzzfeed articles. i then hate myself.

the importance of tightening

why do i offer this story about my most sub-optimal feedback period? to demonstrate the importance of diligence in tightening the loop. wasting a few seconds while waiting hinders you, but waiting enough seconds to distract you with other things slaughters your productivity.

with software development, you can get into a state of what i’ve heard described as “flow.” in a state of flow, the feedback loop creates harmony in what you’re doing. you make adjustments, get quick feedback, and feel encouraged and productive, which promotes more concentration, more feedback, and more productivity. you discover a virtuous circle.

however, just the slightest drop off in the loop pops that bubble. another dropoff from there (i.e., to 40 seconds for me) can render you borderline useless. so much of your professional performance rides on keeping the loop tight.

tighten your loop further

modern tooling offers so many options for you. many ides will perform speculative compilation or interpretation as you code, making builds much faster. gui components can be rendered as you work, allowing you to see changes in real time as you alter the markup. unit tests slice your code into discrete, separately evaluated components, and continuous testing tools provide pass or fail feedback as you type. static code analysis tools offer you code review as you work rather than at some code review days later. i could go on.

the general idea here is that you should constantly seek ways to tune your day to day work. keep your eyes out for tools that speed up your feedback loop. read blogs and go to user groups. watch your co-workers for tips and tricks. claw, scratch, and grapple your way to shaving time off of your feedback loop.

we’ve come a long way from punch cards and sword fights while code compiles. however, in 10 or 30 years, we’ll look back in amazement at how archaic our current techniques seem. put yourself at the forefront of that curve and you’ll distinguish yourself as a developer.