Pitfall: Using the wrong developers

[From Pitfalls of Modern Software Engineering by Bruce F. Webster (forthcoming)]

Categories: managerial

Various industry studies cite the productivity gap between the best and the worst developers. While there is some controversy over the ranges often cited (such as the famous 26:1 figure), anyone who has managed a diverse group of developers won’t argue with the fact that there can be a dramatic difference in productivity among individuals.

What is less obvious is that given a group of developers who are roughly equal in having a sufficient or even superior level of competence and productivity, not all of them will readily adapt to a new language, technology or development approach. Some developers will take to it quickly and do very well; others will have to work harder, but will eventually come up to speed; yet others may never become skilled even though they may not be aware of this fact.

When this happens, all the developers may be working hard, but the relative quality of their work — measured by adherence to best practices for the language/technology in question — can vary dramatically. This may not be apparent for some time, and when it does appear, it can be difficult to correct, from both a technical and organizational viewpoint.

Symptoms

Product architecture that must constantly be revised or refactored. Subsystems that are less stable than others or that are hard to integrate with the rest of the project. Developers consistently complaining about the quality or utility of a given developer’s code.

Consequences

Failure to achieve the expected benefits of the language/technology. Varying quality within the system under development; friction and even serious rifts between team members; project or product failure.

Detection

It’s a big help to have one or more team members who you know are skilled with the language/technology in question. That can be harder to determine than you think, even (or especially) if you think that you’re skilled with the language/technology as well. Process, design and/or code reviews may help to shine light on the problems.

Extraction

This can be one of the hardest issues for a manager, especially if the developer doesn’t recognize the deficiencies. The best solution is probably one of obvious or subtle mentoring: partnering that developer with someone of proven language/technology skills. This approach has two aims: to get the project back on track and to bring the developer’s skills up to speed.

Prevention

Seek the best developers. That may sound obvious, but a lot of companies are more interested in head count than talent and adaptability. The developer should be a self- starter and keenly interested in the language/technology in question, and should also have professional software engineering skills and the discipline to match.

Before the project even starts, spend time to train the developers, and promote the explicit understanding that their language/technology skills will be evaluated on a regular basis. Provide incentives for honesty and alternative assignments, such as building tools, for those whose skills lie elsewhere.

References

Webster, Pitfalls of Object-Oriented Development (1995).

About the Author: bfwebster

Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at bwebster@bfwa.com.