Fast feedback as a first principle

Imagine a painter having to first plan all her strokes, brushes and color mixes in an abstract list and then “execute” a batch of those moves on the canvas and see where that got her. That is obviously an inefficient way to work and would probably not yield the high quality that would be possible if feedback where given after each stroke as is in the real world. But in our craft of software development we are in the habit of creating those batches of work and then see where that get us.

As software developers we have been on the path to shortening our feedback loop for decades. Imagine the leap in productivity when a developer could run code on their own machine instead of having to leave a deck of punch cards to an operator and get the result of running those on the main frame the next day.

The slower the feedback loop is the larger the batches of changes tend to be. That will increase the risk of going in the wrong direction and keep developing on broken code. It also add to the cognitive burden of keeping things in your head, effort that would be better spent focusing on the business problem at hand.

I believe that getting instant feedback is essential to get a truly productive, high quality environment and products.

Agile and lean practices focus on these aspects on the process side of things, but it is as important to have the same fast feedback mindset in your code producing craft. All time waiting for your tools is time wasted and reduces flow.

Lets look at some different areas to get the general principle of fast feedback.

– Development tools
It doesn’t matter if you use an IDE or an editor the principle is the same. Learn your tool by muscle memory. Every time you have to think about an editing action you are wasting time. And if you have to grab the mouse your editor has failed you. Just like a painters brush or a musicians instrument your editor should be an extension of you.

– Hardware tools
Same point here, the hardware supporting your craft should be an extension of you. Have a as good computer as you need for the work you do to not have to wait for it. Chose an OS that are working for you and not against you (not having proper drivers, forcing updates etc). Have a monitor setup that works for you with high quality screens to not cause unnecessary tension on you. The hardware tools also include your desk, your chair and the floor you are standing on. Everything in the physical space around you when you are doing your craft. Every second that you spend on inferior tools is a second wasted from the crafting fast feedback cycle.

– Environment
Find an environment that empower you in your craft. Maybe you work best in an own office, outside in the park or from your home. Whatever it is, do not accept an environment that disturb you and forces you out of the fast feedback flow.

– Hot reloading
Using a run time that can reliably support hot reloading of your code while you develop can be an extreme gain in productivity. Instead of the cycle of
1. start the app
2. create the state of the app that you are developing against (filling in fields etc)
3. check your work
4. take the app down
5. make the code change
6. compile the change
7. deploy the change
8. start the app
9. create the state once again
10. check that the code change was correct

With a hot reloading run-time you instead get:
1. start the app
2. create the state
3. check your work
4. make the code change
5. check that the code change was correct

In my experience, as soon as a developer have developed with hot reloading they never want to go back.

A Read-Evaluate-Print-Loop (REPL) is a great fast feedback tool. As with hot reloading you get an environment that can give you instant feedback when crafting a solution.

– Tests
Tests provide you with fast feedback of the health of your code. The feedback can be both in the regression category but also if you practice TDD, the test is an environment to run your code in. The tests are as any other client and can therefor give you faster feedback than any of your other clients, such as a GUI or starting the debugger.

– Continuous Integration
As with tests but the scope keep increasing. Get fast feedback from units, components, integrations, products and systems.

– Processes
The lean manufacturing methods have lots of good advice on the elimination of waste (“Muda”) and how to drive fast feedback development processes. Check out Poppendiecks book “Lean Software Development: An Agile Toolkit” to learn more about the software way of “Lean”.

These are some examples of how the principle of fast feedback can be applied.

For each situation analyze what is the shortest possible feedback time we can achieve? For your software processes it is reasonable in our day and age to be below 1 second on each code change and on at most daily basis on system level.

One thought on “Fast feedback as a first principle”

Leave a Reply

Your email address will not be published.

4 × three =