Agile principles: feedback

Quick and adequate feedback is important. It’s one of the core principles of agile, after all. However, people keep forgetting about its importance and value. They treat feedback related tasks like timewasters; they would even tell at standups “providing feedback is blocking me” if they could.

What is the best and quickest way of providing feedback – audience say with me – yes, code review. When I hear people presenting results of reviews, most of the times, it’s like: “well it’s ok with me…” I guess this effect can be tracked down to two reasons: laziness and a psychological factor.

Laziness is the obvious one. In order to produce quality feedback one needs to be very careful and thorough. Each and every new code line (and not only – I’ll get back to this immediately) needs be parsed, understood and processed. Are variables and methods named in a self explanatory way? Are methods and classes short enough to be understood with ease? Are unit tests in place, are they really testing the functionality, or are they coverage-increaser-liars? Too many questions to be answered in ten minutes. And in most cases people spend just that much time reviewing (usual case, usual developer, the nature of task to be reviewed does not matter). In order to produce the best possible review comments, some systems thinking is also implied. That’s why not only new code has to be processed; a new question arises: how well it fits into the legacy system? Which can be further broken down into a series of “what if” questions. What if we run the code in a multithreaded environment? What if an exception is thrown? What if we refactored things into several classes/methods? Is it possible, that any part of the new code has already been implemented? (that doesn’t start with “what if”, but happens very often in large systems).

The other reason why we don’t do review thoroughly enough, is that we don’t want to hurt authors’s feelings. Many people think like: “well, I could mention this as a possible comment, but what if they take it as an insult?”. Wrong question. In my opinion any suspicious code part has to be mentioned. Of course in a friendly and supportive manner, and not in “what the hell is this bullshit, dude?” style. Some people will take it personally anyway, but they’ll eventually realize it’s for everyone’s sake.

Further reading on producing quality feedback through code review: Zsolt Fabók’s Basics of code review


Author: tamasgyorfi

Senior software engineer, certified enterprise architect and certified Scrum master. Feel free to connect on Twitter: @tamasgyorfi

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s