One of the key things I promote these days is the constant, continual peer evaluation. This helps solve a large part of the problem with automated unit tests which is that they cannot understand context. The most efficient way I have experienced to do this is the Buddy System. This is a big part of the Jonah Methodology even if they do not promote it on their site (though I think they should).
Remember back when you were a kid on a class trip and you had a buddy you had to stick with for the day (in theory to keep each other out of trouble)? The similar idea applies when developing software. The XP community has been using the Buddy System for years in the guise of Pair Programming. I’m pretty sure that the XPers have produced studies to show productivity games of having pairs of coders sharing a single keyboard but I don’t buy it. What the Buddy System does is take the benefits of having two sets of eyes on a change but without the full time consumption of pair programming.
Here is how the process works:
- Developer A produces some code
- Developer A asks Developer B to Buddy them
- Developer B then sits with A for a session (more on this in a bit)
- Developer B provides feedback on the change and when it is acceptable,
- Developer A then commits their change recording in the the commit notes who the buddy was (you can enforce this using a pre-commit hook if you are using subversion
So what sort of conversations occur during a session?
- Show it working
- Which exceptions are you anticipating and how are they handled?
- Do the existing unit tests all continue to pass?
- Which new tests have you added?
- Any Security issues?
- Can the page / process handle non-English text data?
- Are Corporate/Industry/Company standards met?
- Does it build clean?
- How have you improved the existing code?
Obviously the nature of the change will dictate which questions are asked but those are the big ones in most cases.
The concern people typically have when hearing about this the first time seems to be that it will make their development cycles longer. To borrow from the TDD crowd, it should actually reduce the time (or at the very least maintain it) since there will (in theory) be less rework / debugging associated to changes which have been buddied.
A smart build system coupled with the Buddy System are pretty strong foundations to build a quality system around.
Finally got around to re-reading this… In the context of one of your recent tweets (about how programmers treat quality as “absence of fail” rather than “presence of win”), perhaps the first question the buddy should ask is “How does this help the end user?”
The last question, “How have you improved the existing code?”, doesn’t quite do it. It’s too easy for devs to convince themselves that code needs improved in ways that don’t deliver either direct or deferred value (some technical debt is at 0% interest…)
Of course if you’re doing Agile *properly* you shouldn’t need to ask, because only useful tasks should get put into the backlog. However, I see this as a good opportunity to teach each other YAGNI.