Contents

The Code Review Soapbox

The Mechanics

Code Ownership: A New Meaning

My Least Favorite Question

Code Ownership: A New Meaning

That brings me back to the code ownership question.

Who owns the code? Is it the person who wrote the first rendition? Did the second programmer not write part of the unit? Did the reviewers not approve the implementation? Could the primary reviewer complete a module? Is there any reason a unit couldn’t be started by one individual and completed by another? Don’t we re-use software anyway?

As I have noted over several projects, the code review process intentionally blurs the code ownership issue. In the best case, we had a team that couldn’t easily identify who had written which lines of code just by looking at them. (Is that true in your team?) It could have been any member of the team. That is a strength and mark of success. This particular team had refined its techniques to incorporate all the skills of the team as a whole and replaced variety and confusion to an easily comprehended, consistent style.

I guess I would redefine code ownership this way: every piece of code is owned and comprehended by several people. Beyond that, who cares?

Ah, but there is a good reason to note who the owners are and to note that the “owner” changes over time. The initial implementor is the person most likely to fix a problem the fastest. That’s kind of important to track. So the initiator does tend to “own” the software for a long time. However, they also happen to be the least likely person to recognize a defect in the software (or they wouldn’t have put the defect there in the first place, right?).

Any of the reviewers should make excellent maintenance programmers for units they reviewed, at least for the duration of the defect they are repairing. Hence the reviewers become owners of the software for a time and subsequently they become the best person to fix their own repairs.

Another common practice is for junior programmers to extend the functionality of an existing unit. So they also become owners, too, as do the reviewers of the enhancement work.

See how the ownership gets rather blurred? There are many owners over time. So that also means that the responsibility for successful, continued functioning of a software unit gets shared over time. Not one person is solely responsible for any one piece of code over the life of that unit.

Thus when a single programmer departs for another competing game company, there will always be another “owner” capable of insuring the “abandoned” software remains current and valid for the project. Nothing ever has to be thrown away because the software has been reviewed, approved, and maintained up to the established project standards. The programmer departed, not the software.

Meta-This And Meta-That

What is this “meta-“ thing and why is it so important?

In the case of a meta-design, this is the description of what a design should look like. It details what is sufficient in a design document such that a programmer can build the desired piece of software. A meta-design can be a set of boilerplates.

A meta-meeting is the meeting to decide how meetings are run. Will there be a meeting notice? Who needs to attend? Is there a time-limit? Is an agenda required? Is a note taker part of every meeting? Who steers the meetings, ends arguments, and how? What about publishing meeting minutes?

The point here is that it is essential to have a meta-review. In other words, do not under-estimate the importance of deciding exactly how your group wants to perform reviews, the entire process, over the entire project. You must train and educate everyone in the process. No one can be exempt. Review the review process and refine it.

This also includes defining exactly how nit-picky reviews need to be on a per project basis. This of course means that a group must define the level of software quality they wish to attain. It takes a concerted effort to establish the ground rules. Be sure to include a method to refine the rules.

Idioms & Consistency

Here are two helpful hints to apply to any software project. The first is to employ idioms. In other words, attempt to reduce the coding style and techniques used to a small number of well understood idioms. My latest project used doubly-linked lists for everything and instead of using a “for loop” to iterate through the list, we used a “while loop” comparing pointers for the termination condition. Its just the method we used religiously.

If the team employs idioms consistently, the form becomes recognizable without effort. It also reduces the maintenance issues considerably. Avoid doing surprising things in your software and use copious comments if you have to deviate from the norm. Use of idioms can reduce the comment overhead.

And then, secondly, there’s consistency. Having been employed to develop coding standards and style guides, I can say that consistency is the overall rule of thumb to apply throughout any software project. If you spell a word incorrectly (like “Macintosh”), spell it wrong everywhere. If you employ a flawed idiom, employ it consistently or fix it everywhere. If you use an open brace “{“ with every “if” statement, your teammates should be doing the same thing as should your maintenance programmers.

So when it comes to the code review process, be consistent in applying approval criteria. There should be no mysteries and meeting the criteria should be easy. Be consistent in applying standards, the same standards, to every piece of software and to each individual. Make no exemptions, they’re hard to remember and seldom get documented.

The Benefits Of Code Review:
Insurance
Training
Repeatability
Consistency
Fewer Initial Defects
Lower Maintenance Cost
Re-usable People

________________________________________________________

My Least Favorite Question