TITLE: oo hype and reality (Newsgroups: comp.lang.c++, 4 Dec 96) [ FYI, Robert Martin is now the editor of "C++ Report". -adc ] AHMED: Ahmed > Object Oriented Technology came with quite promising claims that if achieved can benefit the software > development companies and organisations millions of pounds. MARTIN: rmartin@oma.com (Robert C. Martin) Those claims were not made by the engineers and researchers who "invented" OO. They were made by marketeers who found a new way to differentiate products, and by engineers who had shut off their ability to employ critical thinking. AHMED: > Some of these claims for instance > 1 - high reusability of objects and frameworks > 2 - Resilience to change, i.e. low software maintenance and evolution cost > 3 - Easier understanding by the user and Natural transition between the analysis, design, > implementation because they all use tangible perceived objects. > > However the reality is not so bright as claimed..if so, then nobody today thought to develop a > software on the traditional structural methods... > > My question is what is wrong with OO ? why it did not achieved its targets yet.? > What are the main obstacles? MARTIN: The claims were too grandiose. Software is still software; and it is still hard. There are still bugs, still ambiguous specifications, still volatile specifications, still improperly trained engineers, still engineers who shouldn't be engineers, still managers who don't understand the technology they are trying to manage, still arbitrary completion dates, etc, etc, etc. In any case, you shouldn't be surprised when highly publicized claims are not achieved. Generally those claims are just part of the overall hype associated with any new idea. The truth is: (If I may be so bold as to claim to know the truth ;) 1- OO, when properly employed, does enhance the reusability of software. But it does so at the cost of complexity and design time. Reusable code is more complex and takes longer to design and implement. Futhermore, it often takes two or more tries to create somthing that is even marginally reusable. 2- OO, when properly employed, does enhance the software's resilience to change. But it does so at the cost of complexity and design time. This trade off is almost always a win, but it is hard to swallow sometimes. 3- OO does not necessarily make anything easier to understand. There is no magical mapping between the software concepts and every human's map of the real world. Every person is different. What one person percieves to be a simple and elegant design, another will percieve as convoluted and opaque. 4- If a team has been able, by applying point 1 above, to create a repository of reusable items, then development times can begin to shrink significantly due to reuse. 5- If a team has been able, by applying point 2 above, to create software that is resilient to change, then maintenance of that software will be much simpler and much less error prone. In short. Nothing has gone wrong with OO. It is a technology, and it delivers everything it was designed to deliver, and perhaps a bit more. That it doesn't live up to the naive claims made by naive or insincere people is unfortunate, but not unexpected. AHMED: > Is the problem with the immature OO methodologies ( OO analysis and design in specific ) ? MARTIN: No, these techniques have been a major contribution to software engineering, and have gone a long way towards improving the way we build software. AHMED: > or is it the deficiency in the development tools used like C++ or Smalltalk ? MARTIN: No, the tools are more or less adequate for the job. IMHO, someone who blames a language for a failure should be looking a bit closer to home for the cause. AHMED: > or is it the steep difference in thinking between the traditional and OO schools ? MARTIN: I don't think it's the steepness of the difference, although the difference can be very steep. Instead I think that it is the disagreement by OO authorities on the endpoint of that learning curve. For example, some folks will tell you that the secret of OO is think of the world in terms of objects. Others will tell you that it is to think of the structure of the software in terms of polymorphic interfaces. Still others will tell you that it is to decouple the domains of the problem by describing them using macros that can be statically bound at compile time. Which is right? Which is real? There is a *lot* of confusion out there. That some folks might not be experiencing any of the benefits of OO does not surprise me. (BTW, my own choice is one about structuring the software in terms of polymorphic interfaces)