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

CATEGORIES: conceptual

Training is the acquisition of information and practices geared toward a certain end. For example, send a group of engineers to a conference with seminars on object technology, hold a class on C++ programming, or give them a set of books and other materials on object-oriented development. If they’re bright and experienced, they’ll grasp the concepts readily and start applying them, and you’re ready to push ahead. Right?

Well, maybe not. You see, knowledge and even understanding are not the same as skill. Skill comes from experience; it is the ability to use knowledge wisely and effectively. A programmer who has C++ or Java or Ruby syntax down cold still may not know how best to program in that language, the standard idioms, and common errors or pitfalls to avoid.

Going up one level from the language, knowing how to program effectively in a given object-oriented programming language doesn’t guarantee skill in the implementation of object classes or in class hierarchies. And skill in those areas doesn’t automatically translate into skill in object analysis and design.

The same issue holds true for whatever technology or methodology (the “TOM”) that you want to apply. And while you may not be able to personnel who do have those hard-won skills, you need to be able to distinguish the different between training and skill to manage risk and to avoid over-promising (and under-delivering).

Symptoms

Managers who say, “Of course we can do [TOM] development; we’ve sent all our engineers to seminars!” Engineers who say, “Yeah, I’m sure I can pick up [TOM] quickly.”

Consequences

The best consequence is that the developers will realize that they need to develop — or are developing — skills and will adjust their efforts and estimates appropriately. The worst consequence is that no one will recognize or admit the lack of skill, and the project will limp along, slip constantly, or crash spectacularly.

Detection

Ask your engineers and architects to rate and briefly document their skills, talents, and experience — not just their knowledge — in all relevant areas of the TOM. Then have them rate one another. Then rate them yourself.

Extraction

If the project is small in scale, is not critical, or is close to completion, push ahead and finish it. Use it as an opportunity to develop the TOM skills of all the people involved. If, however, the project appears to be at risk and is too important, you may need to do a schedule reset and bring in people (consultants or contractors) who have the required skills in the TOM in question.

Prevention

Skills come only with time and effort. There’s an old aphorism that says: good judgment comes from experience; experience comes from poor judgment. Substitute “skill” for “judgment” and you get the idea of the process. Stephen Covey (in The Seven Habits of Highly Effective People) talks about the Law of the Harvest, referring to our inability to force a crop of wheat to grow overnight or even in a few days.

However, this doesn’t mean that you have to start from the ground floor and build your way slowly. First, find (in-house) or hire (from outside) talent and skill so that you start with people who have a better idea of what to do and how to do it. Next, have them act as mentors, with the other developers as apprentices. The apprentice-journeyman-master system evolved over centuries and has much to recommend it in a profession as craft- and skill-intensive as software engineering. Unfortunately, the short-term focus of most firms doing software development precludes or, at least, hinders that kind of long-term investment.

What if you can’t find or hire skill? Then you’ll have to pay for it in time. Invest in training and use a series of projects, starting small and growing larger, to develop and hone the skills.

Contributor/References

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

Must be able to support all needs of the VP of Customer Support. This includes collaborative thinking in such areas as resource allocation, personnel actions, departmental events, professional development, organizational structure and team building. Additionally includes unwavering support of all decisions made by the VP of Customer Service.

Heh.  Hat tip to Dave Barry (yes, that Dave Barry).