Meta

Posts belonging to Category Software Development

…am I being given a message? In an apparent flash of the Baader-Meinhoff Phenomenon, I’ve suddenly had two encounters in two days with professional development institutions. The first was an advertisement flashed on slacker.com for the Disney Institute, which has such course listings as “Disney’s Approach” to “Leadership Excellence” or “People Management.” The second flash was written on the cup held by a colleague in the office break room, advertising the Chick-fil-A Leadercast. Both titles “Disney” and “Chick-fil-A” didn’t strike me instantly as fonts of divine wisdom, but it’s difficult to argue that successful businesses will indeed be venues for the sages. But getting back to the coincidence…

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.

Software development fads come and go. Whether technology or process, little remains constant it seems. Peer reviews, however, represent one of the exceptions. By “peer review” we are, of course, talking about design reviews and code reviews performed by fellow developers. But do these reviews really add value? After all, peer reviews are part of engineering process, and all too often developers note that process is a mixed bag for productivity. Certainly most every team has a voice that decries peer reviews as counter-productive.

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)

“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.

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]).

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.

For those who are not vocabulary buffs, let’s get our definitions straight:

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:

1

2

3

4

5

6

7

8

9

10

11

12

publicvoidAddBuddy(User buddy)

{

m_buddies.Add(buddy);

try{

ServerDB.AddBuddy(this,buddy)

}

catch(Exception ex)

{

m_buddies.Remove(buddy);

throwex;

}

}

It would be better if it were transformed into this:

1

2

3

4

5

6

7

8

9

10

11

12

13

publicvoidAddBuddy(User buddy)

{

using(ScopeGuard guard=newScopeGuard())

{

m_buddies.Add(buddy);

ObjectGuard inserterGuard

=ObjectGuard.Make(m_buddies,"Remove",

newobject[]{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:

1

foreach(MyClass aClass inMyCollection){aClass.DoSomething;};

An alternative is proposed suggesting we should instead do this:

1

MyCollection.ForEach((MyClass aClass)=&gt;{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.

Us technology wonks are often so geared towards the latest and newest, that we forget or overlook superior solutions from yesteryear. I am, for example, intrigued that it is nearly impossible to find a developer who knows what a “priority queue” is. Instead I’ve seen a number of bad attempts to solve the pertinent problem with ill-suited new technologies.

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?

Having done a great deal of professional web development, I have often marvelled how much effort is necessary to achieve acceptable results. I’ve subsequently cultivated a taste for tools and app leveraging (e.g. Joomla, WordPress). Now I’m contemplating WebMatrix, which went beta this summer. I may just replace my “Google Sites” based blog with a WordPress site made with WebMatrix. For thos interested, take a look at a more official introduction to WebMatrix.

An article at TechCrunch discusses how developer age influences hiring. The point that employers must revisit, the article states, is that “with age frequently come wisdom and abilities to follow direction, mentor, and lead. Older workers also tend to be more pragmatic and loyal, and to know the importance of being team players.” This notion of pragmatism I think is well captured by another article I’m fond of, “Complexity is the Enemy” which had another choice commentary:

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.