Chapter 39. The Transition to OO and C++

FAQ 39.01 Who should read this chapter?

People who are learning OO and C++, but also experienced developers who have to get others through the paradigm shift.

This chapter is partially written for people who are learning OO and C++, but it is also aimed at those who already have the technical knowledge, but are trying to guide others through the cycle. It is based on our experience training and mentoring thousands of developers in different environments. Our insights are as much psychological as they are technical, because the goal is to set realistic expectations and then help as many people as possible succeed.

FAQ 39.02 What are the key messages of this chapter?

The key messages are

1. Know the stages of development, and set appropriate goals.
2. Books are necessary but not sufficient.
3. Courses might help but are not sufficient.
4. Experience on significant projects led by competent mentors is very important.
5. Small projects build the wrong skills and attitudes for success on large projects.
6. C expertise can hurt more than it helps.

FAQ 39.03 How many stages of technical expertise are there in the transition?

There are at least four different stages of technical expertise.

1. The first objective is to be able to play a useful role on a project, with technical assistance from others. Sometimes referred to as “grunt programming” or “blue-collar programming,” there is a need for solid citizens who can take work direction and do most simple tasks on their own.
2. The next step corresponds to the “senior developer” role, and the main difference from level 1 is the ability to work without detailed technical direction on all but the most difficult problems. People at this level have usually worked on at least three significant C++ projects and have made a fair number of mistakes. Most developers attain this level of competence eventually.
3. At the next level, the developer is thought of as the “resident guru” or technical expert in one or more aspects of C++ development. These are the people who come up with the bright ideas and technical leadership for their organization, and are usually spread across several projects. Their salaries can be quite high, and they usually have no interest in management career paths. The good ones have a large amount of scar tissue and arrow wounds in their back. Very few programmers have the intelligence and dedication necessary to reach this level of expertise.
4. At the final level, the person is the “industry thought leader,” and very few organizations can afford one of these exotic specialists. These are the true experts who are well known in their peer group. It is unrealistic for most developers to aim for this level of expertise, and those who achieve it spend almost every waking hour maintaining their craft. People of this caliber are usually brought in as consultants rather than hired as full-time employees.

FAQ 39.04 Why bother defining levels of expertise?

Because it is important to set realistic targets for the transition plan.

In the early years of OO and C++, many organizations decided that they needed to develop expertise quickly, and many poor souls were “chosen” to become resident experts. They were given a book to read, subjected to an intensive two- or three-week training course and a few months of experience with a trivial project. These battlefield promotions did not work very well, and the organizations have suffered from having created anointed “experts” out of people who are actually at level 1 in their development. These organizations have a hard time developing legitimate skills at any level because their “top” people are clueless.

So the first task is to get the trainee to level 1 and to recognize that not everyone will make even this transition. The hard part is recognizing that everyone, no matter how experienced or talented, has to start off at the bottom rung. OO is radically different from functional decomposition and requires a “paradigm shift” that can be quite difficult for strong-willed people. C++, if used properly, is quite different than traditional C, even though it can be used as “a better C” (this latter approach does not deliver the promises of OO, however). Finally, object modeling is quite different than data modeling. People who were strong in the older technologies have significant emotional and intellectual hurdles to leap, and they should not be expected to immediately reach their previous level of expertise in the new technologies.

In our opinion, organizations should focus on getting people to level 1 through training, reading, and mentoring. With experience and additional mentoring, many of the level 1 people can eventually attain level 2. Anything beyond that is beyond the scope of this book and probably depends more on talent and attitude than on organizational process.

FAQ 39.05 Can OO/C++ be learned from a book?

A good book can teach syntax and semantics, and a great book can open your eyes, but that isn't good enough.

We think the book you are reading is a good book, maybe even better than that. But a book can't reinforce its messages like practice does, and a book can't answer questions like a good mentor can. It has been our experience that incremental technology, such as going from FORTRAN to C, can be picked up by good people from reading a book and experimenting a bit. But a paradigm shift, such as transitioning to OO and C++, doesn't lend itself to this traditional approach.

So, learn by reading, but become proficient by doing, particularly under the tutelage of a pro. A book alone cannot get you even to level 1.

FAQ 39.06 Can OO/C++ be learned from a course?

No. Courses are like books, helpful only if the objective is very limited.

We have found that courses are a great way to learn specific skills, such as how to use a tool. But they can't convey the depth of knowledge that is needed for learning something as deep as OO and C++ in a reasonable time frame. Most of the instructors aren't up to the task technically (they are educators, not developers, and lack the experience and scar tissue that is needed). Even if the instructors are great (we think we've been pretty good instructors ourselves) and the material is wonderful (but when was the last time a great developer knew how to develop great pedagogical material?), the key is still to do something real.

One of our classroom experiences was predictable: we preached the gospel about OO design and the students nodded their heads approvingly. But when we gave them their first miniproject, they did things the way they always had. It takes time and repeated effort to break old habit patterns.

In our opinion, it is possible to get a talented person to level 1 with a combination of good courses and good books, but it takes both ingredients.

FAQ 39.07 What is the key to learning OO/C++?

Serve an apprenticeship on a real project with a top professional.

A good mentor has level 3 to level 4 technical skills, good one-on-one communications skills, and a practical orientation backed by sound judgment. Mentoring is difficult because it requires patiently responding to off-beat questions while still getting work accomplished. The apprentice has the opportunity to ask questions in a real-world environment, and learning when “rules” should be broken in the name of practicality. Another part of the learning process is listening to “war stories” and tales of failure that cannot be discussed formally.

Real projects are important because classroom exercises and books fit the subject matter into neat theoretical compartments. A live project is essential to see how theory and practice coincide and overlap and to develop the background for making practical trade-offs.

Good mentors are worth whatever they charge, but watch out for the bad ones. Avoid technology bigots who know the answers before they've heard the question: a good example would be people who automatically hate anything from Microsoft (or, equally bad, automatically love anything from Microsoft). Also, there are many people who talk a good game but have never finished anything of significance. In particular, there are people who will put their version of OO theory and “purity” ahead of project success. Look for practical mentors who have built something and lived with the consequences of their actions. Avoid people who have been on lots of projects but never saw anything through to completion.

FAQ 39.08 Are small projects a good way to get your feet wet?

No. Small projects can set you up to drown later on.

Small projects, whose intellectual content can be understood by one intelligent person, build exactly the wrong skills and attitudes for success on large projects. In terms of thousands of lines of code (KLOC), anything under 20KLOC is clearly small, and anything over 100KLOC is not small. The experience of the industry has been that small projects succeed most often when there are a few highly intelligent people involved who use a minimum of process and are willing to rip things apart and start over when a design flaw is discovered. A small program can be desk-checked by senior people to discover many of the errors, and static type checking and const correctness on a small project can be more grief than they are worth. Bad inheritance can be fixed in many ways, including changing all the code that relied on the base class to reflect the new derived class. Breaking interfaces is not the end of the world because there aren't that many interconnections to start with. Finally, source code control systems and formalized build procedures can slow down progress.

On the other hand, big projects require more people, which implies that the average skill level will be lower because there are only so many geniuses to start with, and they usually don't get along with each other that well, anyway. Since the volume of code is too large for any one person to comprehend, it is imperative that processes be used to formalize and communicate the work effort and that the project be decomposed into manageable chunks. Big programs need automated help to catch programming errors, and this is where the payback for static type checking and const correctness can be significant. There is usually so much code based on the promises of base classes that there is no alternative to following proper inheritance for all the derived classes; the cost of changing everything that relied on the base class promises could be prohibitive. Breaking an interface is a major undertaking, because there are so many possible ripple effects. Source code control systems and formalized build processes are necessary to avoid the confusion that arises otherwise.

So the issue is not just that big projects are different. The approaches and attitudes to small and large projects are so diametrically opposed that success with small projects breeds habits that do not scale and can lead to failure of large projects.

FAQ 39.09 Does being a good C programmer help when learning OO/C++?

No. A good C programmer is almost always a horrible OO/C++ programmer.

One of the early ideas behind C++ is that it could be used as a “better C” without using its OO or modern software engineering features. We don't think this is a desirable approach in most instances, and this book is written for organizations which want “good” OO software using C++, not just C++ programs that compile and execute correctly. With that perspective, this is the new reality for C programmers:

• The use of arrays is evil. C++ now uses container classes.

• The use of pointers is evil. References are “in.” When pointers are used, reference counting is “in.”

• The beloved type casts of all sorts are bad.

• Using code to find code is evil (that is, using type information and if and switch statements and downcasts to locate the right routine to call). In C++ we use virtual functions and dynamic binding.

• Good old-fashioned char* delimited by '' is evil. In C++ we have strings from the class library.

• Familiar functions such as memcpy() and strlen() either have nasty behavior or are obsolete.

So, what's left from C that's “good” C++? Curly braces and semicolons, and that's about it. Not only do C programmers have to throw away quite a bit of old technique, they also have to pick up a few new ideas:

• Templates

• Exceptions

• Mutable

• Inheritance and hiding rules

• Operator overloading

• Virtual functions, abstract base classes

• Special characteristics of STL or the class library of your choice

• Constructors and destructors, new[] and delete[]

• Declare at first use, where no one can find it

• And on and on and on.

Okay, we'll admit that we've had our tongue planted firmly in our cheek while writing this FAQ. It isn't quite that gloomy, and hundreds of thousands of C programmers have learned to program successfully in C++. But, our message is that the transition isn't automatic or easy, and C programmers better be prepared for a major intellectual challenge if they want to become good C++ programmers.

FAQ 39.10 What skills help when learning OO/C++?

Being able to see the big picture and solid software engineering skills.

Invariably the most successful OO/C++ developers (those that reach levels 3 and 4) share a set of core beliefs.

• They love designing interfaces, they use programming by contract techniques, and they see the value of decoupling as an architectural goal.

• They understand why interface reuse is more valuable than code reuse.

• They are committed to building high-quality software systems in a team-oriented environment rather than just making sure their small piece compiles and runs.

• They are willing to try new techniques, rather than rejecting new ideas because they've never used them before.

• They understand the costs of using code to find code and they avoid it religiously.

• They realize that requirements are always changing and they work hard at designing interfaces that are flexible and extensible.

• They know what they know and they know what they don't know, and they are willing to seek out good advice in an effort to find better solutions.

• They would rather understand how and why something works than be satisfied with simply getting something to compile and run.

• They put the good of the many (the client code) ahead of the good of the few (the system code), and they understand that “breaking client code” is very expensive.

• They understand the cost and benefits and risks of alternative approaches and factor them into their decision-making process.

• They design changeability into the fabric of the system architecture and design, rather than thinking of “change” as an afterthought or maintenance activity.

• They do not believe that one size fits all.

• They listen before they speak—they do not have an answer before they hear the question.

• They want to understand why the software is being built—the underlying business case—in addition to simply knowing what the requirements are.

• They consistently put business considerations ahead of technology considerations.

Developers with these skills will thrive when using C++ no matter what their background was—C programmer, Smalltalk programmer, Cobol programmer, former CEO, or itinerant sheepherder.