Recap

The biggest problem with this approach is that it does tend to focus on the "programming in the small" issues. Each new language that comes along has more expressive power, and often that power is not shown off by using small examples. For instance, it is hard to see how this example would help you understand the inheritance feature of C++, although I am sure you could find a way.

What I have observed over and over again is that the majority of developers use the subset of the latest language that allows them to get the job done. Only a very few effectively use the "power features" that are often touted in the books and in the hype surrounding the new language. It also concerns me that these languages are more sophisticated to the point that when power users employ the most advanced features, the code becomes very obscure to the average programmer. This is especially dangerous when one considers that the maintenance of the code will be done in almost all cases by a programmer who is less competent than the person who wrote the original code. This is not a slam on modern programming languages; it is an advisory to managers to be sure that the code they produce will be maintainable over the long haul.

We now pass to the last chapter in our section on software differences. This involves that little-known art called "Getting the Product Out the Door." It is what we get paid for, and, I am sorry to say, in too many cases we are not very good at it.