MentorGraphics pioneered the use of C++ for large scale commercial development.  They had become a successful supplier of electrical engineering CAD tools by offering the most tightly integrated series of products in the industry. They sought to exploit objects as a means for continued growth.  Instead, the company stumbled with the release of  version ''eight-dot-oh'', 
which became known as ''late-dot-oh'', 
and then even worse, ''late-dot-slow''.  The hiccup opened the door to competitors that Mentor probably could have squashed had they not had their hands full with so much technology.  Executives placed the blame for their poor performance squarely on C++.

'''What Went Wrong?'''

A fellow who joined the company early in the effort quit after a month or two.  He said that the effort was sure to fail since all the designers were suffering under an extreme case of SecondSystemSyndrome -- the desire to make the second system do ''everything'' that was missed in the first.

Here's an example.  The first product filed data using a database that had been coded up brilliantly in Pascal by one of the founders.  Every developer knew its limitations and most knew a dozen ways to get around them.  The C++ replacement was a storage framework that offered a wide variety of access methods, all nicely wrapped up with abstractions and interfaces and all that.  But which one to use?  Many poor choices were made based on who-knows what criteria.

The original plan called for writing a framework and then rewriting each application against that framework.  The framework was slow in coming.  Customer demand had application developers adding new features to the old Pascal code while they waited. By the time the framework was out no team could justify using it.  Only late in the game did anyone look into ways of running the Pascal in the new environment.

A lot of extremely skilled engineers worked incredible hours for what must have been at least two years.  Many kids only saw their dads/moms when they came to the Mentor facilities for the free family lunches offered on weekends.  What was the problem?  Did they do something wrong?  

I don't believe objects to be the source of the problem.  Rather, I think management grossly underestimated the amount of function that had been built into the original products. They did so simply because the products had been coded by a small number of people in a short period of time.  Until we as a discipline come to understand peak programmer productivity and integrate it into the practice of CompetitiveDevelopment we will always be at risk of duplicating Mentor's ''late-dot-slow'' experience.  
-- WardCunningham