Code Oversight
A relatively important practice in Agile is the use of multiple pairs of eyeballs to help ensure that the code that is being delivered is of the highest quality possible. Quality in the context means low defects, good design, adherence to local standards, and suitability to the task at hand.
There are several ways to achieve this goal:
- Pair Programming
- Peer Programming
- Open Source Committer Model
- Formal Code Reviews
Pair Programming
In Pair Programming, all production code is written in pairs – two programmers working together at one machine. Pair programming has been shown by several experiments to produce better software at similar or lower cost than programmers working alone.
This is a rather controversial practice – the concept of not working alone is foreign to many programmers. However, Pair Programming acts as a real-time code review, and it has a distinct peer pressure aspect to it. Programmers are more likely to develop test-first, follow coding standards and refactor their code when there is someone working with them!
Research by Dr. Randall W. Jensen while he was working for the U.S. Air Force spoke of two-person (2P) teams. At the time of the report, 2P teams had been in use since 1975. Initially, there was concern that there would be lost productivity owing to having 2 people work on the same problem. However, the study showed productivity improvements of over 150% at the time scale of a month.
Similar research by Laurie Williams at North Carolina State University has indicated that there is a 15% overhead when programming in pairs, i.e. it takes 15% longer to develop the same code as when it is written by individual programmers. However, the 15% overhead is more than made up for by the reduction in defects and the higher overall design quality of the code. Also notice that the overhead is only 15%, as opposed to the expected 50%. This indicates that two programmers working together are indeed working faster than when they are alone.
Pair Programming, though, depends on total engagement by both people involved. If one simply acts as a passenger, it is indeed a waste of time. The social aspects can be uncomfortable for some people, although it can be argued that software development in general is a social exercise and it requires the level of collaboration that pairing provides.
Peer Programming
In this model, developers may work alone but they must have another developer commit their code to source control. This means that the second developer will perform a quick code review, and work with the first developer if any issues are identified.
This provides the benefit of a second pair of eyes reviewing the code, but doesn’t provide the real-time feedback that Pair Programming does.
Open Source Committer Model
Most open source projects have a very small group or even a single person who is authorized to commit code to source control. There may be many, even hundreds, of people creating code and submitting it for review. Considering the number of highly successful open source projects, this model does have merit. For situations where the development people are widely distributed geographically, it can be particularly effective.
The assumption, though, is that the committers have time available to be able to review submissions. A committer must have the talent and in-depth knowledge of the system to be able to verify that submitted code is able to be committed. Because committers are reviewing, they aren’t able to work on as much production code where that talent and knowledge may be better applied.
Formal Code Reviews
The traditional form of code review involves multiple team members reading selected code line by line to critique the design and style and search for defects. There are processes and tools available to facilitate the review process, including a number of open source and commercial tools to help ensure adherence to coding standards and static analysis of the code for potential issues.
While this review method is not without merit, it’s current use has become generally limited to safetly and life-critical applications, with the other methods increasing in popularity.
These posts may also be interesting...
Smaller User Stories?We are the Borg
Every little thing
What problem are you trying to solve?
There’s a new look around here
Product Management
comments powered by Disqus