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

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