5 Development Team Productivity Killers

July 16th, 2007

Here are 5 things that will seriously harm the productivity of a software development team. They are:

1. Not Sharing Information
2. Not Using Peer Code Reviews
3. Not Enforcing Coding Standards
4. Not Using a Version Control System
5. Not Using the Appropriate Technology

I’ve seen these things slow down and even kill several projects both in VB and other languages. In this article I’ll go over these common problems and give you some solutions to help you deal with them.

1. Not Sharing Information

It is common for programmers to horde information, particularly from newly hired developers or contractors or from members of other development teams. Why do they do this? There can be several reasons. One typical reason is pure office politics, protecting ones own position in the department and company. Certain human resources policies, like Forced Ranking, can
encourage this behavior. Others may include a fear of criticism by others or feeling protective about others possibly changing their code. Some may even feel like they’re protecting the company from losing valuable intellectual property by withholding key information from other developers.

This kind of ‘tribal chieftain’ knowledge quickly becomes a liability to the company because new developers have to constantly bother the ‘chief’ with questions, thus lowering the productivity of both. Even worse, it can kill team morale if the ‘chief’ is difficult to deal with. And, should the ‘chief’ leave the company, often development projects are thrown into chaos for months.

The solution to this problem is to encourage a free flow of information and find ways to reward it. For example, you may create a mentoring program where a long time developer is given the task of spending some time with new developers to get them up to speed. Or a ‘lunch and learn’ program could be implemented that would allow a small group of developers to discuss things over an always popular free lunch. These approaches and others like them usually build team cohesiveness and spread knowledge more evenly throughout the department.

2. Not Using Peer Code Reviews

Some people view code reviews as a waste of time, a productivity killer, but I think the opposite is true. As mentioned in the first item, too often one programmer doesn’t know what the other is doing. Peer reviews are another way to encourage knowledge sharing. Also, from a productivity stand point, having an extra set of eyes check the code will greatly reduce costly rounds of maintenance since often a programmer is too close to their code to spot problem areas or simply miss things that they meant to repair and forgot about later.

3. Not Enforcing Coding Standards

Nobody likes be in the role of ‘code police’ but some commonality is needed when more than one person is working on a project. If everyone goes and does their own thing it makes code harder to review and maintain. The most important thing here is to come up with an agreed upon standard and stick to it. You may want to use a VB.NET standard coding guideline like this one or you may want to continue to use old style VB6 standards. But, whichever you pick, stick with it and enforce it.

As a side note to this, any good coding standard should include comments. .NET makes this easy with XML Comments since it provides an easy to use and documentation tool friendly common template for them. Of course, you can use your own standard here but XML comments make this task much easier in .NET.

4. Not Using a Version Control System

This is common in organizations that started out small with one or two developers and expanded. Nobody had the time to implement a version control system or there wasn’t money in the budget for it. Soon, as the number of developers increase, the problems start. Nobody is sure which code is actually in production. Programmers find their code doesn’t work or is left out of a release. Rolling back to a previous version is impossible since nobody knows where the original code is located. Hacks to get things to work become commonplace. Soon the whole development process is bogged down in trying to maintain code that can’t be pieced back together.

You can save this kind of trouble by implementing a version control system from the start. It will more than pay for itself in the long run.

Also, everything should go into version control, not just application code. Web pages, documentation, and especially database table structure and stored procedure scripts should be included as well.

5. Not Using the Appropriate Technology

Too often programmers get stuck in the “I have a hammer so everything looks like a nail” approach to designing and developing applications. For example, a team may spend time developing a web based application when a desktop one would be a better choice or vice-versa. Another common trap is to always use a 3rd party code library for everything when it is only appropriate for a small subset of applications. Productivity often suffers when programmers try to force a square peg into one of these round holes. I’ve seen small projects expand into huge, time consuming, death marches because of the insistence on using an inappropriate tool for the job.

Avoid this trap by evaluating the practicality of a programming tool or method for a task early in the design phase. Don’t wait until coding has begun to do this. Also, don’t get stuck in the mode of declaring that all projects will use such-and-such a tool and so forth. Don’t shut out your options without proper evaluation on a per project basis.

Entry Filed under: Development Teams

Rate This Article:

(1 votes, average: 5 out of 5)

 Loading ...