The following is a sidebar that appeared in the Communications of the ACM, Special Issue on Object-Oriented Application Frameworks, Vol. 40, No. 10, October 1997.
Developing complex distributed applications is expensive and error-prone. As a result, contemporary organizations are increasingly faced with a ``distributed software crisis'' -- computing hardware and networks get smaller, faster, and cheaper, yet distributed software gets larger, slower, and more expensive to develop and maintain. The challenges of building distributed software stem from inherent and accidental complexities [Brooks:87] associated with distributed systems:
Over the past decade, we have worked with many companies and agencies (including Motorola, Sprint, Ericsson, Siemens, Bellcore, Kodak, and McDonnell Douglas, the Naval Research Laboratory, and Bently Nevada) building reusable OO communication software frameworks and applications. In these projects, we've applied a range of OO middleware frameworks including OMG CORBA (an emerging industry standard for distributed object computing middleware) and the ACE framework (a widely used C++ framework that implements many strategic and tactical design patterns for concurrent communication software). The following are lessons learned from developing and deploying reusable OO communication software components and frameworks in practice:
Many political, economical, organizational, and psychological factors can impede successful reuse of distributed software. We have found that reuse-in-the-large works best when (1) the marketplace is competitive (i.e., time-to-market is crucial, so leveraging existing software substantially reduces development effort and cost), (2) the application domain is non-trivial (i.e., repeatedly developing complete solutions from scratch is too costly), and (3) the corporate culture is supportive of an effective reuse process (e.g., developers are rewarded for taking the time to build robust, efficient, and reusable components).
When these prerequisites do not exist, we have found that developers often fall victim to the "not-invented-here" syndrome and rebuild everything from scratch. Unfortunately, this forces them to rediscover and reinvent the core distributed software concepts and components, which is time-consuming, error-prone, and expensive.
Expanding on the corporate culture theme, we have observed that it's crucial for top-level software managers to openly support the fact that good components, frameworks, and software architectures take time to craft and hone. If this support does not occur, we've found that many developers and project managers will take the path of least resistence and not risk their schedules and budgets by planning for reuse. Therefore, for reuse to succeed in-the-large, organizations must have the collective vision and managerial resolve to support the incremental evolution of reusable software.
In many domains, we've observed that an 80% solution that can be evolved and optimized is preferable to trying to achieve a 100% solution that never ships. Fred Brook's observation that ``Plan to throw the first one away, you will anyway'' [Brooks:75] applies as much today as it did 20 years ago.
A time honored way of producing reusable components is to generalize ``bottom-up'' from working systems and applications. Most of the useful components and frameworks we've encountered emerge from solving real problems in domains like telecommunications, medical imaging, avionics, and transaction processing. Therefore, we advise resisting the temptation to create ``component teams'' that build reusable frameworks in complete isolation from application teams. We have learned the hard way that without intimate feedback from application developers, the software artifacts produced by a component team won't solve real problems and will not be widely reused.
Expecting emerging industry middleware standards (like CORBA, DCOM, or Java RMI) to eliminate distributed software complexity today is very risky. For instance, although lower-level middleware implementations (such as ORBs and message-oriented middleware) are reaching materity, the semantics of higher-level middleware services (such as the CORBA's Common Object Services and Common Facilities) are still vague, under-specified, and non-interoperable. However, despite the fact that higher-level middleware frameworks aren't quite suited to meet demanding real-time performance and reliability requirements in certain domains, we expect that over the next two years we'll see middleware products emerge that support such features [Schmidt:97].
While developing high quality reusable software is hard enough, developing high quality extensible and reusable distributed middleware framework software is even harder. Not surprisingly, many companies attempting to build reusable middleware frameworks fail -- often with enormous loss of money, time, and market share. We've noticed that the fear of failure often encourages companies to pin their hopes on silver bullets that will slay the demons of distributed software complexity via CASE tools or point-and-click wizards.
Unfortunately, simple solutions to complex problems that sound too good to be true typically are... For example, translating code entirely from high-level specifications or using trendy OO design methodologies and programming languages is no guarantee of success. In our experience, there's simply no substitute for skilled software developers, which leads to the following final ``lesson learned.''
Ultimately, reusable components are only as good as the people who build and use them. In our experience, cultivating high quality software developers is time consuming and expensive. Ironically, many companies treat their developers as interchangeable, "unskilled labor" who can be replaced easily. We expect that over time, companies who respect and reward their high quality software developers will increasingly outperform those who don't.
On the other hand, the bad news is that (1) existing OO components and frameworks are largely focused on only a few areas (e.g., GUIs), (2) the skills required to successfully produce distributed middleware remain a "black art," and (3) existing industry standards still lack the semantics, features, and interoperability to be truly effective throughout the distributed software domain. Too often, vendors use industry standards to sell proprietary software under the guise of open systems. Therefore, it's essential for end-users to work with standards organizations and middleware vendors to ensure the emerging specifications support true interoperability and define features that meet distributed software requirements.
To support the standardization effort, it's crucial for us to capture and document the patterns that underlie the successful distributed software components and frameworks that do exist. Likewise, we need to reify these patterns to guide the creation of standard frameworks and components for the distributed domain. We are optimistic that the next generation of OO frameworks and components will be a substantial improvement over those we've worked with in the past.
[Brooks:75] Frederick P. Brooks, "The Mythical Man-Month," Addison-Wesley, Reading, MA, 1975.
[Brooks:87] Frederick P. Brooks, "No Silver Bullet: Essence and Accidents of Software Engineering," IEEE Computer, Volume 20, Number 4, April 1987, 10-19.
[Fayad:96] Mohamed E. Fayad and W.T Tsai and M.L. Fulghum, "Transition to Object-Oriented Software Development," Vol. 39, No. 10, January 1996.
[OMG:95] Object Management Group, The Common Object Request Broker: Architecture and Specification 2.0, July, 1995.
[Schmidt:96] Douglas C. Schmidt, "A Family of Design Patterns for Application-Level Gateways," Theory and Practice of Object Systems, Wiley and Sons, 1996.
[Schmidt:97] Aniruddha Gokhale, Douglas C. Schmidt, Tim Harrison, and Guru Parulkar, "Towards Real-time CORBA," IEEE Communications Magazine, Volume 14, Number 2, February 1997.
Back to ACE home page.
Last modified 11:34:18 CDT 28 September 2006