Tag Archives: code

The Joy of Peer Reviews (Part 1 – Code)

Posted on by
Reply
Reading time ~ 2 minutes

Pair programming replacing peer reviews is a myth in the same way that “agile projects have no documentation”.

From my experience peer reviews continue to hold a vital place in agile development and software craftsmanship. Unfortunately they are often misunderstood or misapplied.

“Humanizing Peer Reviews” by Karl Wiegers is the best primer I’ve read so far on peer reviews so I’m not going to duplicate Karl’s efforts – I strongly recommend a thorough read. In fact, print a copy and give one to every member of your delivery team to read and discuss.

Like everything else in modern software development, peer reviews are a collaborative team learning experience. Reviewing code properly means both the reviewer and reviewee walk away having learned something and improved their craft.

With code reviews; beyond reviewing for functional correctness, (the simplest, most obvious and potentially quickest part of a review) there’s a selection of considerations I expect reviewers to look for. (There are plenty more).

  1. No code without tests
  2. Good variable naming
  3. Correct use of classes and interfaces
  4. Small methods
  5. Adherence to standards and conventions
  6. Style consistency across the team
  7. Readability
  8. Good test coverage from small tests
  9. Test code follows the same quality standards as production code
  10. Tests describe expected behaviours
  11. All tests pass
  12. Evidence of some test preparation to consider boundary cases, failure modes and exceptions
  13. Clear exception handing, failure modes and explicit boundaries
  14. Sensible error messages
  15. Code smells
  16. Performance risks or tuning opportunities
  17. Security or other “ility” issues.
  18. Opportunities to learn new tricks
  19. New good practices & patterns
  20. Functional correctness

Once you have cultural acceptance on the breadth of technical peer reviews develop your own checklist that everyone supports and remember the goal of a review is to share improvement opportunities, not for lazy coders to have someone else find their bugs for them or for staff to step on each other.

Now…

If you think peer review of code is problematic for your teams, I guarantee that document peer reviews will be a whole lot worse! – see part 2.

Writing Code is NOT a Value-Add Activity

Posted on by
Reply
Reading time ~ < 1 minute

I’ve been working through David Anderson‘s last book; “Kanban“. Last Night towards the very end of the book I had a lightbulb moment.

When taking a lean approach to software development you need to focus on value-add activity. David’s acid-test for this is very smart – I paraphrase below…

“If it’s really a value-add activity, then you should be striving to do more of it”

Now, consider this. Are we writing code or delivering working valuable software that solves a customer or user business need?

Some of you may have worked in organizations that considered measuring programmer performance by lines of code produced. Like all great metrics, there are some fair reasons for measuring LOC but with the wrong motivation, it will drive the wrong behaviour. You’ll produce more lines of code but not more value.

So…

Writing code is not a value-add activity. Producing working software that our customers and users need is.

Remember the concept of 4GLs – the more coding activity you could automate, the more real output you can get.

This approach is still relevant. Great software development teams automate as much of the coding as possible so that teams with strong domain expertise can focus on only writing the advanced business logic and don’t have to worry about the scaffolding.