Why Engineering Teams Should Measure Feedback Time
1 min read

Why Engineering Teams Should Measure Feedback Time

Programming speed depends a lot on feedback time - the time between writing code and testing it.

The worst bug I ever had to fix involved two machines in different buildings. I would make a change on one machine, and then have to walk 15 minutes to the other building to see if it had worked. This was one of those bugs where you don't know what's wrong exactly so you keep testing hypotheses until you find a clue. I tested somewhere between 20 and 30 before I figured it out. I walked a lot that day.

What made this the worst bug ever wasn't the bug itself - it was the feedback time. The time between me writing code, and being able to test it. Programmers intuitively know that feedback time is important and we tend to optimise for it. We love keyboard shortcuts, use browser developer tools, and we built HMR.

Programming involves a lot of trial and error. You start with a rough solution, write the code for it, compile/build/deploy it, test it, and then adjust the code again until it works. The time you spend waiting between writing and testing code doesn't just slow you down because it takes time, it also breaks flow and tempts you to context switch if it's long enough. These all have a huge impact on productivity. Think about how much faster you can iterate on the front-end of a website using your browser's developer tools, versus working on a back-end that you have to compile each time you make a change.

Even though this is something engineers intuitively understand, it's not something that many organisations work to improve. I suspect this is because it's not measured often. If you're an engineer and want to change this, there is probably a business case to be made by calculating your teams' total feedback time per week and multiplying it by salary for a lower bound.