I suppose the first ad was to be expected.  Those hidden corporate ties and browser cookie snoops likely gleaned that I’ve been looking at executive coaching books.  And I admit I just got done reading “The Five Dysfunctions of a Team: A Leadership Fable” by Patrick Lencioni, ordered online.  This is a book I’m so impressed with that, well, it’s the real reason I’m writing this post.  Normally I’d discuss hands-on technical or software development matters, but honestly far too much of project success depends on people issues.  I highly recommend, neigh, imperatively commend serious professionals to digest this book.  One of the Amazon reviewers outlined the five dysfunctions clearly, so rather than repeat that verbage here, I’ll simply high-light one point that greatly struck me.

Lencioni discusses how conflict in the office, often expressed as spirited arguments during meetings, are generally viewed distastefully in the U.S. corporate setting.  And the higher in the management chain the arguments occur, the higher the fear that such episodes will be viewed as a personal failing of management.  Thus there is a tendency to suppress arguments, either in duration or frequency – or perhaps forbid them altogether.  Lencioni explains that this policy or reaction is misguided, and reveals how suppressed argumentation actually causes much more harm and wasted time than is “saved” from bypassing them!  Obviously he recognizes and qualifies what constitutes a productive and non-productive argument, so that only the fruitful arguments occur and, ironically, occur regularly.

Having given this tidbit, now it’s time for me to turn my attention to the next “professional development” subtle hint from the universe.  If you are reading this post, it might be your subtle hint as well.

The truth is that value in peer reviews depends on two independent factors.  First, there is a correct and incorrect way to perform a peer reviews.  The studies which repeatedly show a significant positive impact from peer reviews, assume a specific model of how they are conducted.  Second, peer reviews require two elements of successful team dynamics. 

Let’s look at both of these more carefully.

Peer Reviews Done Right

What many organizations call “peer reviews” are actually not.  Usually the term is misapplied for what is actually a “walk-through.”   The distinction pertains to both purpose and format, and has significant ramifications for quality and schedules.  Whenever possible it is peer reviews that should be exercised, not walkthroughs.  Let’s look closer at the differences.

In a walkthrough, the purpose is to impart familiarity with design or code to the rest of the team.  The format assumes the author presents the content as others listen and ask questions.   Besides the author, usually this is the first exposure anyone has to the materials.  There can be any number of participants, including management.

In a peer review, in contrast to a walkthrough, the purpose is to locate defects. 

• “All participants prepare by reading the design or code and looking for errors…The emphasis is on error detection” (McConnell, p493)
• “Code review is systematic examination (often as peer review) of computer source code intended to find and fix mistakes” Wikipedia, “Code Review.”
• “An inspection in software engineering, refers to peer review of any work product by trained individuals who look for defects using a well defined process” Wikipedia, “Software Inspection”

Other positive benefits are welcome, such as knowledge transfer and training, but are considered secondary in purpose.  The format assumes that someone other than the author conducts the review.  Furthermore, the materials being reviewed are sent (3 days) in advance of discussion.  Most of the reviewing work is done before participants gather together.  The optimal number of participants is three, including the author.  Management should not attend.

Again it must be emphasized, to achieve the advertised benefits of peer reviews, they must actually be peer reviews, not walkthroughs.  Don’t confuse the two!

Team Considerations.

If there is an objection to peer reviews, it usually centers on fear of judgment or personal attacks.  When this objection surfaces, it should be a red flag to managers of broader team problems. 

For a team to be successful, the members must trust the others will not attack them personally.  If that trust exists, then fear of conflict subsides.  This does not mean that conflict does not happen but, rather, that no one takes debate personally.

This is not some kind of rarified dynamic that only applies to successful peer reviews.  It is a dynamic that teams need with or without peer reviews.  Thus if team-mates complain that peer reviews engender hostility that must be avoided, then there certainly is a meta-issue that should be addressed.

Peer Reviews: The Benefits (ROI)

The following bullet points drive home why peer reviews are not an empty procedure. Soak yourself in them.

• Identified as one of 9 principle industry best practices by the Airlie Software Council.  Examples of corroborating results:
  • Hewlett-Packard’s inspection program measured a return on investment of 10 to 1, saving an estimated $21.4 million per year. Design inspections reduced time to market by 1.8 months on one project
  • Inspections contributed to a ten-fold improvement in quality and a 14 percent increase in productivity at AT&T Bell Laboratories
  • Inspecting 2.5 million lines of real-time code at Bell Northern Research prevented an average of 33 hours of maintenance effort per defect discovered
  • IBM reported that each hour of inspection saved 20 hours of testing and 82 hours of rework effort had the defects found by inspection remained in the released product
  • At Imperial Chemical Industries, the cost of maintaining a portfolio of about 400 programs that had been inspected was one-tenth the cost per line of code of maintaining a similar set of 400 uninspected programs
• “Typical organizations use test-heavy defect-removal and achieve only about 85% defect removal efficiency.  Leading organizations use a wider variety of techniques and achieve defect-removal efficiencies of 95%.” McConnell p470.
• “Jones (“Software Defect-Removal Efficiency” 1996) points out that a combination of unit testing, functional testing, and system testing often results in a cumulative defect detection of less than 60 percent, which is usually inadequate for production software.” (p471).  Code inspection and test runs both produce about as much defect detections.  However, the variety of defects found vary sufficiently that a combination of both techniques produces almost double the defects detected (Myers 1978b [McConnell p 470]).
• Testimony of Jeff Atwood
• FINDING: “A study at the Software Engineering Laboratory found that code reading detected about 80 percent more faults per hour than testing (Basili and  Selby 1987).  Another organization found that it cost six times as much to detect design defects by using testing as by using inspections (Ackerman, Buchwalk, and Lewski 1989).  A later study at IBM found that only 3.5 staff hours were needed to find each error when using code inspections, whereas 15-25 hours were needed to find each error through testing (Kaplan 1995). [McConnell, p470]
• FIXING: Microsoft’s applications division has found that it takes three hours to find and fix a defect by using code inspections, a one-step technique, and 12 hours to find and fix a defect by using testing – which is a two-step technique (Moore 1992).  Collofello and Woodfield reported on a 700,000 line program built by over 400 developers (1989).  They found that code reviews were several times as cost-effective as testing – a 1.38 return on investment vs. 0.17. [McConnell, p471]

Final Notes

Two more points should be made about successful peer reviews.  First, a peer review that does not identify defects – is suspect.  It usually means either that reviewers had insufficient review time, or that they haven’t the correct skill set to review the materials.  Second, peer reviews should not wait until the materials are complete.  Ideally the work of design or coding should be approximately 50% complete before being reviewed.  This gives time for redirection, if that is necessary.

If members of your team are reluctant to get started, even with all the compelling rationale, I suggest you make your own materials the first to be reviewed.  There’s nothing like leading by example.

Pedantic: a narrow, often tiresome focus on or display of learning.

And that is exactly what kind of programmer we’re going to examine today.   It is a symptom of being a mid-level developer, who over-zealously tries to use the techniques of a senior developer. 

Certainly some people, if you are fortunate, have no idea of what I’m talking about.  But to be clear, and to allow introspection for those of us who might need it, I will give a couple solid examples.  One example involves exception handling and the other involves the ‘foreach’ statement.  These “are two basic topics,” you might say, so “what possible harm could someone do?”

Pedantic Exception Handling

I love CodeProject.  If you are not already a fan, be sure to check it out.  It has countless fantastic articles, although it has one case of pedantism which is fodder for this presentation.  That particular article summarizes by saying that when you see exception-handling code like this:

public void AddBuddy( User buddy )
{
    m_buddies.Add( buddy );
    try        {
        ServerDB.AddBuddy( this, buddy )
    }
    catch( Exception ex )
    {
        m_buddies.Remove( buddy );
        throw ex;
    }
}

It would be better if it were transformed into this:

public void AddBuddy( User buddy )
{
    using ( ScopeGuard guard = new ScopeGuard() )
    {
        m_buddies.Add( buddy );
        ObjectGuard inserterGuard
            = ObjectGuard.Make( m_buddies, "Remove",
                        new object[] { buddy } );
        guard.Add( inserterGuard );
        ServerDB.AddBuddy( this, buddy );
        inserterGuard.Dismiss();
    }
}

Why does the author claim the latter exception handling is better than the former? Well because the first example, the author states, has “reduced readability.”  The second example the author admits is annoying given the need “to pass the ‘Remove’ method name” as untyped data, but overall he claims it “is more elegant and more practical than the usual try, catch and finally triad.”  He goes on “of course, there will be a performance hit due to the use of reflection.”

He must be a comedian.

Almost all developers understand how the exception handling works in the the first example.  In contrast, nobody but the author knows what on earth the second example is doing and yet the two examples are functionally equivalent.  The truth is, the author just wanted to show he knows how to use reflection. That is what makes it pedantic, and a detriment to the team who is confronted with the noise in the product code.

But let’s take one more example.

Pedantic Looping

Many developers are taking quickly to LINQ functionality in C#.  It’s powerful stuff.  And it is also an opportunity for the pedantic programmer to show-off needlessly.  Indeed, I’ve seen cases where programmers have endeavered to replace the “foreach” statement with an extension method.  In other words, instead of doing this:

foreach(MyClass aClass in MyCollection) {aClass.DoSomething;};

An alternative is proposed suggesting we should instead do this:

MyCollection.ForEach((MyClass aClass)=>{ aClass.DoSomething; });

I’m much relieved to see that Microsoft’s C# team has dismissed the idea, but of course that won’t stop the pedantics from writing that ‘ForEach’ extension, to show-off their ability to write extension methods and use lambdas.  The rest of us must simply navigate around the nonsense when reading such code.

Conclusion

Perhaps we proud programmers are all pedantic to some degree.  But certainly it is good to be reminded of the KISS principle, and to focus our talents on solving problems rather than making solutions looking for a problem.

Of course, as Billy Joel sang “the good old days weren’t always good.” But achieving the best result certainly comes from a judicious balance of old and new. Just how profound that can be is amusingly apparent when considering the ability of a bee to solve the “traveling salesman” problem. Just how old are those computers the bees are using?

I’ll be tinkering…

After some time we move into the role of mid-level software engineer. We’ve been through a few projects and we’ve built up confidence and spent a lot of time reading books and articles about software engineering, best practices, and the design principle/pattern of the day. We’re ready to rocket ahead and show everyone around us how smart we really are – that we’re not juniors anymore.
In other words, we’re now ready to do real harm.

I certainly acknowledge that many older developers may sink into technical apathy, but I think “older with experience” is still a prime place to find the greatest developers.

What the article did not explain is that each appdomain you create (even those created recursively, as in my case) must be explicitly unloaded before terminating the process – to create a clean execution environment. But I finally got it working, and now I’m able to run dozens of inter-linked servers through scores of full-blown integration tests in seconds, and all from within a single process, on a single machine, launched from my Visual Studio unit-test IDE.

Now that is cool!

1. Make the level-editor before the game prototype.
2. Next, make a prototype – do not make a game engine.
3. Finally, get some graphics in to help keep motivated.

Normally such “making of” articles discuss technical or game design details. So it was nice to see this particular departure offering such “attack strategy” wisdom. The article had other excellent advice as well.  A worthwhile read.