© Conrad Weisert, Information Disciplines, Inc., March, 1999
NOTE: This document may be circulated or quoted from freely, as long as the copyright credit is included.
We keep hearing about yet another object-oriented fiasco, a major project that incurs massive cost and schedule overruns or gets abandoned after a huge investment. Even when functionally satisfactory software gets delivered on time and within budget, the end product often turns out in the long run to be outrageously costly to maintain.
Two major causes of this sad situation are:
The two are closely related, since little ongoing skills development occurs without supporting infrastructure, but I'll focus here on the skills issue.
Although organizations that suffer from poor software development performance are usually willing to concede their shortcomings in the infrastructure area, they almost always vigorously defend their staff's (or contractor's) skill levels. In doing so, however, they often reveal a simplistic view of what it means to be fluent in using a complicated tool, like C++ or Java. We hear managers make assertions:
Those managers apparently believe that knowing C++ or having been trained in C++ is an all-or-nothing accomplishment: One either has C++ skills or one doesn't, according to their view. Sometimes they'll acknowledge two levels of C++ skill:
"Jerry took the advanced C++ course, so now he can lead the design team."
C++, with its essential component libraries, is a vast collection of facilities based on the subtle and, for beginners, unfamiliar object-oriented paradigm. Its difficulties and complexities are far from one-dimensional; after mastering the basic concepts and language constructs2, the programmer can pursue a variety of specialized follow-on areas3. "Advanced C++" has no meaning.
Many C++ and Java "experts" who have mastered one or two supposedly advanced areas are utterly ignorant of others. For example:
Moneyclass nor understand why one would be necessary or desirable in the huge financial application they were developing for a large insurance company!
Practically no one ever masters the whole collection, which keeps growing in size and complexity as new features and standard library components get added. Even if we could freeze language development, we'd all continue to gain new insights through experience, and those insights would have to be shared with our colleagues. Managers who don't understand and accept this are almost certain to get poor quality results.
Return to IDI home page.
1 See article Methodology Development and Administration.
2 See article C++ Training -- Unique Challenges and course Making the Switch to C and C++
3 See Advanced C++ Seminars
Last modified October, 2003