Part I – Ode to Joy

Since the launch of the seminal “Joy” work which hopefully doesn’t need mention here, we’ve seen everything from The Joy of Cooking to The Joy of Not Working (my personal favorite!), and so further to that deeply mined vein of authoritative works we bring you the necessarily over burdened… Joy of Code Review!

Joy, you say? Let me count the ways…

• I implement a task, using what I consider to be best practice patterns and guidelines; I slave over this, my creation, and when it’s done, I stand back and admire, much in the tone of an old master, this latest image of my greatness.
• Then I remember I need to get it reviewed…
• So, I timidly invite my Architect and 3 of his best friends to the war room to review my new baby
• After many rescheduling pauses, we finally gather…
• I hold my breath, turn on the projector, and bare my soul to the collective seniors in attendance
• 30 minutes later, having endured a ritual mind flaying, and the predictable but nevertheless enjoyable tortured examination of my parentage, education, upbringing and such fun rhetorical musings as “why do they let people like you graduate?” I slink out
• Follow up is, if anything, more painful as I’m reminded moment-by-moment of just how badly I’ve lived up to the expectations laid out for me by the senior team members

Anyway, so code reviews suck, amirite? But we all know we need to do them. Of course, we all know we need to do them for completely different reasons from each other…

• Kids right out of grad school know they need to do code reviews because although their code is, like, totally perfect, it’ll be good to show the old dudes their skillz, and for the old dudes to check out some rad new stuff that they might have missed along the way.
• Senior guys know they need to do code review because otherwise all kinds of terrible cruft will get promoted into the head branch and somebody (are you looking at me??) will have to fix it…
• Managers know they need to do code reviews because they read all about them in a book with a cool cover, and it’s all Agile and stuff, and let’s face it they’re being measured on code review coverage, so come hell or high water you’re going to do code reviews!
• And of course, regular professional developers know that code reviews, however painful, genuinely lead to better code, regardless of the pain involved in getting there.

What we have here, folks, is a social organization, complete with the crazy uncle, the embarrassing grandma and the pimply teenagers. And social organizations, as we’ve all come to know and love, are at their best when the forum in which they’re fostered exists for a reason that encourages the unstated, but nevertheless in-your-face activity of which those in the respective societal groups are desperately in need:

• Facebook? Getting a date. And then getting another one while simultaneously trying desperately to avoid the previous partner. Rinse/repeat. Seriously, I have no idea how kids manage today. At least when I was young and awkward we could hide behind the silence and foot shuffling of real face-to-face meetings. Now with a keyboard and the internet in the way, there’s nowhere to hide!!!! I’m off topic again… ahem…
• Linked-In? Getting a job.
• Myspace? Getting a clue.

You get the idea.

So code review as a social engagement… really? Parts 2 and 3 of this series of posts will examine how such interactions, fostered by social networking tools, are the best way to ensure code review gets done and returns value both to the participants and to the companies in which they work.

In part one of Going Agile,I talked about how we introduced Agile to our development team. This next post will look at the events that led to our first iteration planning meeting.

During the weeks that led up to Iteration 1, there was much work that went on as a team, and much that each team member did individually. As the Product Owner, my biggest task was to create a backlog. Sure, I knew what the main new features were going to be, but I still needed to capture this, and add other oft-requested features. I scoured every correspondence I had with customers, sales, support, development, and so on to gather this information.

After everything was said and done, I had a pretty massive backlog… a pretty massive, unprioritized backlog. At this point, I really didn’t know any good techniques for backlog prioritization (that would change after attending the CPO training with Mountain Goat Software). This training was not going to happen for a few months, but something needed to be done… so I did what any good Product Manager does…I used the ‘wet finger in the air’ technique. Now, my ‘estimations’ were based on a number of concrete data points and some not-so-concrete assumptions and anecdotal evidence, so they weren’t totally of the ‘wild-assed guess’ ilk. After a few more days I had my backlog read for the team.

While the backlog creation was going on, a number of team meetings were occurring. Two of the more important meetings involved creating rules for the team and preparing our definition of “Done” . I highly recommend spending some time up front on both of these activities.

Creating the team rules was a great exercise, because it was the first time the team sat down as a collective and decided what the rules would be. Many of the rules were not groundbreaking…things such as everyone’s opinion is equal, treat everyone with respect, don’t be late for meetings, and when and where daily Scrums were going to happen.

The best result from this meeting centered on the team’s communication methods. Everyone was already using email, so that was covered. Instant messaging was rolled out to the team, and everyone was to use it. Of course face-to-face discussions were encouraged the most, but there needed to be some way to let people know you didn’t want to be disturbed (unless something was urgent). Everyone created a Do Not Disturb sign, and when it was posted, it was to be respected. Sometimes people just need to focus on the task at hand, rather than constantly being disrupted. We came out of that meeting with a clear set of easy-to-understand team rules, and we posted these rules in our team conference room for all to see. Note… rules can and will change over time.

Next was coming up with our definition of Done. The team sat down for a couple of hours to determine what should/should not be included. Looking back, we thought we were cavaliers and were blazing new trails with the definition we came up with…in reality, we put together a definition that was pretty much in line with the ‘industry norm’. One thing that we did not include initially was code reviews…that is, for a story to be considered done, the code had to be reviewed by at least one other developer (who was not associated with that piece of code). During our Iteration 1 retrospective, we modified our definition of Done, and code reviews became part of it. In fact, this definition of Done may go through many, ahem, iterations before becoming finalized.

Finally, we needed to get our ‘room’ set up and have all the necessary supplies on hand. Our team decided to use a wall board with color-coded cards for the tasks. Green cards were for development tasks, red cards were bugs, blue cards were for testing tasks, and yellow cards were for documentation tasks. Now we just needed a board to pin these tasks to. We didn’t want to spend a small fortune on a big pin-board, so we got creative and used carpet under padding. (You can get a huge piece of this at any DIY store for next to nothing and it works like a charm.) We fastened it to the wall, put on some masking tape borders and labels, and we had ourselves a Scrum board.

So with our prioritized backlog, team rules, definition of Done, and Scrum room all set, we were now armed and dangerous, and ready for our first iteration planning meeting…TO BE CONTINUED.

Good first day at ESC Boston2009. Gwyn and Alen presented a well attended talk on using source code analysis (SCA) to improve developer productivity. Key takeaways from the presentation:

• How SCA will impact your development velocity
• Quick history on SCA – talked about lint and the general evolution of the technology
• How the information generated by static code analysis can be used to solve a variety of development challenge
• Demo of where SCA fits from a code review, refactoring and bug detection standpoint

Interesting change from past presentations where most people now understand the basics of the technology… no need to spend too much time talking about its history and technology building blocks.

The presentation was recorded so we’ll load the video up at a later date for everyone’s viewing pleasure :)

Jason certainly hits the nail on the head.  Automation, specifically using static analysis, is key and it should be tightly integrated with your code review. Although we need to be careful where we label source code analysis.  Static source code analysis certainly can find those low level issues such as labeling your local variables correctly, but it goes beyond simple code style issues.

Where static source code analysis can really help is with the deep inter-procedural context that it can provide.  For example, during a code review you go through some code with a number of function calls.  Hopefully you know what each and every function is doing…but do you really?  This is where the deep analysis of static source code tools can help.  It can help you identify that there may be an issue in the code review and that issue happens to show that a function is returning NULL.  Uh oh, potential null pointer dereference on our hands.

Now add code reviews with other static source code technology, such as full source cross reference information, flowcharting, impact analysis for any function/methods and architectural representation to show you the full context of the system.  Now you’re talking powerful.