Code Review vs. Code Inspection

Can we skip code inspection process?

In his novel, The Deadline, Tom DeMarco gives an interesting sample about reducing project development time by removing verification stage from the development process. Well, I'm sure it's possible for an excellent team, but unfortunately it's still too extreme for most of project teams in the real world.

However, code inspection process is a bit different thing.

Can you imaging that experienced developer, who always created exemplary code, will start working in a slapdash manner? Yes, if that person has some personal problems, is bored by the project, has a conflict with another team member, or the like. But it's all about management, not about programming.

Professionals, who keep working in the same area, won't lose their knowledge and experience! Thus, there is no need to continue inspecting project code if several recent reviews confirmed that the code is in good condition. It's just waste of time, nothing more.


Code Review vs. Code Inspection?

It's a common thing, to mix Code Review and Code Inspection terms. However, these two process have different goals. While Code Inspection is focused on verification that source code corresponds to coding rules, guidelines, and has no obvious smells; Code Review helps finding defects and creating a base for code refactoring.

Most areas of code inspection process can be automated (e.g. Static code analysis). Code review can not. In fact, this is a cornerstone of code reviews - using a human brain to read and understand the code, looking for defects with a fresh eye. Peer code reviews remain the best approach for finding code defects (Sergei Sokolov. Bulletproofing C++ Code. Dr. Dobb’s Portal, January 09, 2006).

On average, 60 percent of defects can be removed via code reviews (Barry Boehm, Victor R. Basili. Software Defect Reduction Top 10 List. CeBASE, January 2001), so it's really helpful to introduce regular code review process when the code is being actively created.

500% productivity increase

Recently, I received an invitation to a Users' Conference that was dedicated to one RAD (rapid application development) tool. In other words, it was going to be a product presentation.

New technologies and ideas are always interesting. So I browsed Internet for some additional information about the product, and was very surprised when I found the following statement on the tool home site: ... is for developing, generating, and maintaining applications with an increase of productivity of up to 500%.

Of course, I didn't support that event...


It's a pity, that year to year IT people continue believing in some easy magic solution that will help them to upgrade their coding style, and start developing software products much faster than everyone else. Tom DeMarco and Timothy Lister wrote about the same problem in 1987... It's about 20 years ago, and nothing changed in this area.


Let's make some calculations.

Software development process consists of different activities including requirements analysis and documentation, programming, user documentation, testing, data processing, communication, management, and so on.

Industry statistics give different results, but usually programming part varies between 30 and 50 percents of total project cost.

It means that even if we automate programming process completely and it won't require any human effort at all, the project cost can not be reduced more than twice without improving other development process stages. So up to 500% productivity increase should be read as up to 42% of a project cost saving.

42% of a project cost saving? It would still be very very good, if it is possible!

A lot of developers are conservative enough, but almost each company has some enthusiasts who bring news to their teams. And if they finds something extraordinary, all team members will hear about it shortly.

So, to be 6 times (500%) away from some modern published technology, your development team has to be about 450% behind average industry programming speed. If it's the case, then it's easier to change the team than to try new technology ;-)


The following table lists some SLOC /Funtion Point values(the information is taken from QSM Function Point Programming Languages Table). A lot of languages are not being extensively developed during last years. They are quite stable and even corresponding frameworks and libraries do not grow as fast as before. At the same time, up-to-date SLOC/FP values show that these languages can compete with their more modern competitors. It's one more argument, which confirms that average software industry productivity is not increasing as fast as someone dreams.

Programming Language	SLOC / FP
Smalltalk	35
Visual Basic	50
JSP	59
C#	59
Perl	60
Java	60
C++	60
ASP	69

Myth about 80-20 rule

80-20 rule... Does it sound familiar? Oh, I'm pretty sure that all of us heard about it or even used it in business. There are a lot of incarnations:

• 20% of people owns 80% of world capital.
• 20% of your sales force produces 80% of your company revenue.
• 80% of your outcomes come from 20% of your input.
• 20% of employees makes 80% of work in a company.
• ... and 80% of employees think that they belong to those 20%.
  

and so on.

Internet is full of articles extolling this rule and its variations. I have even seen a series of books promoting a life style that is based on 80-20 principle. And it's good, until readers (and writers, I hope) remember that the figures are fake in most cases... Almost all these rules were declared without even a single statistical analysis!

Someone can say, that I'm trying to mess everything, and these rules are not about the figures, that the rules simply highlights correlation between the least part of input and the major part of output. True... but just sometimes. In other cases the results can be completely different.

Below, there are two statements that deal with the same subject as few rules listed above:

• IT people does NOT spend more than a half of their day doing nothing.
• Healthy IT company does NOT afford itself to have even 25% of useless employees. 75% would simply kill the business.

Does these statements look truthful too?

Pareto principle is great itself. Its mathematical wording is exact. But it is being misused so widely, that I would recommend to think twice before making conclusions on the base of some 80-20 rule, even if it's very popular one.

How much does an employee cost?

The case

There was an employee working for a company. He was really good in some activities, but he also got some negative feedback because of few impartial and several biased reasons. At the result, his boss decided not to raise the salary, and after few months that guy left the company.

This event created urgent demand for a new person who can take that position, and the company finally was able to find a candidate "on time":

• As always, new person required some training for that particular position;
• That new person was less qualified than a guy that had left the company, but it was the best choice in terms of cost/qualification;
  
• The company had to pay newcomer higher salary, than the previous employee would be satisfied with...
  

The question

So how much does an employee cost?


The answer

The case almost answers this question itself... Actually, it's even possible to provide exact formula (I think I can), but who really cares?..