misuses. While I believe that the data accurately represent an important relationship, the numbers are far too precise. (They are undoubtedly the precise average of several imprecise numbers.) Each language has a domain of usage. Visual Basic is very expressive and powerful in building simple interactive applications, but it would not be a wise choice for a real-time, embedded, avionics program. Similarly, Ada 95 might be the best language for a catastrophic cost-of-failure system that controls a nuclear power plant, but it would not be the best choice for a highly parallel, scientific, number-crunching program running on a supercomputer. Software industry data such as these, which span application domains, corporations, and technology generations, must be interpreted and used with great care.
Two interesting observations within the data concern the differences and relationships between Ada 83 and Ada 95, and between C and C++. The interest of the Department of Defense (DOD) in developing Ada 83 was due in part to the increase it would provide in expressiveness. (Other reasons included reliability, support for realtime programming, maintainability, and improved ROI through language standardization.) A significant economic motivation was the ability to develop a program in substantially fewer lines of code than were required in the traditional language alternatives of FORTRAN, COBOL, C, and assembly. Embodied in the Ada language are numerous software engineering technology advances, including language-enforced configuration control, separation of interface and implementation, architectural control primitives, encapsulation, concurrency support, and many others. Ada 95 represented a well-planned language upgrade to accommodate new technology and incorporate lessons learned in field applications. The difference in expressibility between Ada 83 and Ada 95 is mainly due to the features added to support object-oriented programming. Thus, a first-order estimation of the value of object-oriented programming is that it allows programs to be written in 30% fewer source lines.
The difference between C and C++ is even more profound. C++ incorporated several (although not all) of the advances within Ada as well as advanced support for object-oriented programming. However, C++ was also developed to support C as a subset. This requirement has its pros and cons. On one hand, the C compatibility made it very easy for C programmers to transition to C++. On the downside, one noticeable trend in the industry is a significant population of programmers using a C++ compiler but programming with a C mindset, therefore failing to achieve the expressibility of object-oriented C++. The evolution of Java has eliminated many of the problems in the C++ language (particularly the native support for C, which encourages several dangerous programming practices) while conserving the object-oriented features and adding further support for portability and distribution.
Universal function points can be used to indicate the relative program sizes required to implement a given functionality. For example, to achieve a given application with a fixed number of function points, one of the following program sizes would be required:
1,000,000 lines of assembly language 400,000 lines of C 220,000 lines of Ada 83 175,000 lines of Ada 95 or C++
The values indicate the relative expressiveness provided by various languages. Commercial components and automatic code generators (such as CASE tools and GUI builders) can further reduce the size of human-generated source code, which in turn reduces the size of the team and the time needed for development. Extending this example, adding a commercial database management system (DBMS), commercial GUI builder, and commercial middleware could reduce the effective size of development to the following final size:
75,000 lines of Ada 95 or C++ plus integration of several commercial components
Because the difference between large and small projects has a greater than linear impact on the life-cycle cost, the use of the highest level language and appropriate commercial components has a large potential impact on cost. Furthermore, simpler is generally better: Reducing size usually increases understandability, changeability, and reliability. One typical negative side effect is that the higher level abstraction technologies tend to degrade performance, increasing consumption of resources such as processor cycles, memory, and communications bandwidth. Most of these drawbacks have been overcome by hardware performance improvements and optimizations. These improvements are far less effective in embedded platforms.
There has been a widespread movement in the 1990s toward object-oriented technology. I spend very little time on this topic because object-oriented technology is not germane to most of the software management topics discussed here, and books on object-oriented technology abound. Some studies have concluded that object-oriented programming languages appear to benefit both software productivity and software quality [Jones, 1994], but an economic benefit has yet to be demonstrated because of the steep cost of training in object-oriented design methods such as the Unified Modeling Language (UML).
By providing more-formalized notations for capturing and visualizing software abstractions, the fundamental impact of object-oriented technology is in reducing the overall size of what needs to be developed. Booch has described three other reasons that certain object-oriented projects succeed [Booch, 1996]. These are interesting examples of the interrelationships among the dimensions of improving software economics. (Quotations are presented in italics.)
1. An object-oriented model of the problem and its solution encourages a common vocabulary between the end users of a system and its developers, thus creating a shared understanding of the problem being solved.
a Here is an example of how object-oriented technology permits corresponding improvements in teamwork and interpersonal communications.
2. The use of continuous integration creates opportunities to recognize risk early and make incremental corrections without destabilizing the entire development effort.
a This aspect of object-oriented technology enables an architecture-first process, in which integration is an early and continuous life-cycle activity.
3. An object-oriented architecture provides a clear separation of concerns among disparate elements of a system, creating firewalls that prevent a change in one part of the system from rending the fabric of the entire architecture.
a This feature of object-oriented technology is crucial to the supporting languages and environments available to implement object-oriented architectures.
Booch also summarized five characteristics of a successful object-oriented project.
. 1. A ruthless focus on the development of a system that provides a well-understood collection of essential minimal characteristics
2. The existence of a culture that is centered on results, encourages communication, and yet is not afraid to fail
3. The effective use of object-oriented modeling
4. The existence of a strong architectural vision
5. The application of a well-managed iterative and incremental development life cycle
These characteristics have little to do with object orientation. However, object-oriented methods, notations, and visual modeling provide strong technology support for the process framework.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.