Fast Feedback

At a recent visit to the Science Museum, I spotted this at the 3D printing exhibition:

"With traditional manufacturing a lot of preparation time is needed to make a new part; sometimes special tools need to be developed and built. 3D printers require little preparation and no special tools. We can test our designs and make changes much more easily. This speeds up our design process and lets us experiment with new ideas."
3D Printing: The Future of Industry (PDF), the Science Museum

I thought this was pretty cool. For me it describes why fast feedback is so useful and it's pretty clear that the points apply equally to software.

Feedback Failures

"You don't learn to refactor by being told. You learn to refactor by experiencing the alternative -- and then remembering what you were told."
Uncle Bob, The Domain Discontinuity

It was reading this line that sparked this post. I pondered if people did always learn this way. It’d be simple then, right? Unfortunately, I don’t think this is always the case, and this made me ponder other ways that feedback can go wrong.

Software feedback can relate to several aspects of software; here, I'm going to consider the vague notion of our software's design, though most of the points apply more broadly than this. I'm assuming that any feedback we do get is of high quality to narrow the scope. My examples don't mention user feedback, again to narrow the scope.

Let's start from the bottom.

Silence

You're not getting any feedback. 

You're not consuming your own code in other modules or unit tests.

You're not getting feedback from other developers, be that through code review, pair programming, or a cry of despair coming from the direction of the person consuming your code.

This is the absolute worst state to be in. Your output has practically no chance of improvement until you get out of this position. This is probably a team-wide issue and as such needs discussing with your entire team; its culture almost certainly has deep issues. Also, start writing tests and start using your software! If it’s front-end, play about with it for a while. If it’s back-end, try interfacing with it. A revelation, I know.

Deafness

You’re not hearing the feedback that you are getting.

"The Expert Beginner has perfected the craft of bowling a 160 out of 300 possible points by doing exactly the same thing week in and week out with no significant deviations from routine or desire to experiment. This is because he believes that 160 is the best possible score by virtue of the fact that he scored it."
Erik Dietrich, The Rise of the Expert Beginner

You’re consuming your code, but don’t notice that this is painful. Perhaps you consider this “the way complex systems have to be” and won’t acknowledge that the pain is self-inflicted. 

You’re completely ignoring the feedback given from your peers. It’s going in one and ear out of the other, or you’re reading it and instantly dismissing it.

This is a dangerous state to be in. As alluded to above, it’s quite possible that you have ventured into expert beginner territory. Getting out of this position is about accepting that, in all likelihood, you're some way from mastery.

Powerlessness

You’re hearing the feedback, but you don’t know what to do with it.

"You cannot expect to produce quality code just by listening to your test. If you don't know what good code looks like, you are pretty much test deaf."
Sandro Mancuso, Test Deafness

You hear what your tests are telling you -- this class is too hard to initialise, for example -- but you don’t know what to do about it. 

You listen and understand the problems highlighted by your peers, but you don’t know how to resolve those problems.

Thankfully, we can often escape this state quickly. Studying is in order, preferably in collaboration with peers.

Lateness

You’re hearing the feedback, you know what to do with it, but you're hearing it too late.

You’re writing your tests after you’ve already baked in a rigid, highly-coupled design.

You are doing code reviews with your peers, but by the time the feedback comes, many people are already consuming your API and a breaking change would cause too much pain.

Any benefits the feedback would have had have been lost. That’s feedback in itself, though, and a solution here should be obvious: shorten the feedback loop. Write your tests first instead of as an after-thought; try pair programming instead of code review; release early, release often.

Greatness

You’re hearing it, you know what to do with it, and it’s timely.

"Continuous delivery and ongoing optimisation of our working practices is a platform for true excellence, not excellence itself."
Jason Gorman, Software People Inspiring

Greatness happens. Or at least, if you keep this feedback loop going, you’re on the road to it.