The Commercial Case For Object Oriented Software Development

The Commercial Case For Object Oriented Software Development
Mark Collins-Cope

PDF version

---

1. Introduction

This whitepaper looks at the factors influencing the cost of software development and maintenance, and explains how by adopting the Object Oriented (OO) approach to software development software costs are reduced.

When companies first venture into developing bespoke software systems, they are often surprised that the cost of the software development is two or three orders of magnitude greater than the cost of the hardware on which the software will run. And that’s even before they’ve considered the cost of maintaining their systems.

To explain the reasons for these costs it is necessary for us to take a step back and look at the issues underlying the economics of software engineering looking at the two main areas of costs:

• those that are incurred during the development of systems,
• those that are incurred during the maintenance of systems.

Finally, this whitepaper takes a look at the more recent trends towards distributed systems, and the costs associated with these.

2. Development Costs

2.1. Low Level Building Blocks Equals High Cost Of Development

There is no getting away from the fact that the development of large software systems is one of the most complex engineering feats achieved by man. Programming languages offer infinite flexibility in the way software may be built. If you ask two software developers to write the same system, it is quite likely that they will come up with completely different implementations to meet the same set of requirements.

One of the reasons for this is that the building blocks provided by traditional programming languages are at such a low level. Writing a piece of software with a procedural programming language is rather akin to building a suspension bridge out of matchsticks and a tube of superglue: the design possibilities are infinite but, assuming you manage to build your bridge, you’re likely to end up with a maintenance nightmare!

The addition of facilities to assist in the structuring of software has been one of the major focuses of programming language improvement over the years, however procedural programming languages still leave much to be desired in this area. As the complexity of the software systems we develop grows (a trend which is showing no sign of abatement - note the more recent moves towards GUI, client/server and three-tier systems) the ability to manage and organise the complexity of software is becoming even more of an imperative than it is at present.

The Object Oriented approach to software development offers a route out of this quandary by providing a mechanism with which to build the higher level building blocks necessary to manage this complexity: Objects.

An object is a well defined software building block that provides a set of services (its methods or operations) to its users (i.e. other software developers) in such a way that they can use these services without having to worry about exactly how they work. Furthermore, OO programming languages enable the building block provider to define the structure of the object (its class) leaving it to the user of the class to create as many objects of any particular type as they need.

To see the benefit of this, consider a high street banking system. The system will manage thousands of accounts, but the behaviour of each account will be identical, providing facilities to: record debits; record credits; print statements; and calculate monthly charges.

Figure 1 - An account object using the UML notation

Having the account as a fundamental system building block will obviously be of great benefit in such a system, and OO programming languages enable us to build such objects by defining an Account class enabling the application developer to create instances of these Accounts (a.k.a. objects) as is necessary for the particular application they are developing. Note that this approach has significant benefits over the more traditional Cut’n’Paste approach to software development, where an area of code is copied when similar functionality is required in another part of an application, not the least of which is that it doesn’t involve copying a multiplicity of bugs around the application as well.

The OO approach, when adopted using appropriate development methods, encourages re-use of code within the application. Since the number of bugs within a system is generally proportional to the number of lines of code written, any approach which reduces the number of lines of code written (and designed, and debugged, and tested, etc.) offers cost benefits, as well as guaranteeing more consistent behaviour within the application.

On the related subject of code re-use across applications (such as sharing the account object described above across many applications), Jeffrey S. Poulin reports in his book Measuring Software Re-Use (Addison Wesley) a number of impressive statistics, some of which are detailed below:

• Nippon Electric acheived 6.7 times higher productivity 2.8 times better quality through a re-use programme
• GTE Corporation saved $14M in costs of software development with re-use levels of 14%
• Toshiba saw a 20-30% reduction in defects per line of code with re-use levels of 60%
• A study of nine companies re-use showed re-use led to 84% lower project costs (!), cycle time reduction of 70%, and reduced defects.

2.2. Experience is an Expensive Commodity

Traditional software does not encourage code re-use, for the reasons already discussed in this whitepaper (lack of appropriate building blocks, etc.). Obviously once an account object has been defined, it can be re-used repeatedly, with the consequent cost savings.

However, the concept of re-use (equals reduced costs) can be applied at the analysis and design levels as well as at the coding level. One recent innovation in the world of OO is the emergence of design and analysis patterns as an area of interest in its own right.

Patterns enable the experiences of expert developers to be captured in a form that is easily communicated to less experienced OO developers, enabling them to shortcut the ‘learn from your mistakes’ approach that their more experienced colleagues were forced to adopt.

NOTE: Enlarge the diagram below by clicking on the picture.

Figure 2 - Use of a standard design pattern (“strategy”) to provide database independence

If the banking system we discussed earlier is supplied by a product company to a variety of banks, one problem they will face is that each bank will have its own preference for relational databases. To deal with this problem, the product company must provide a framework which removes their system’s dependency on the database. This somewhat common software engineering problem is easily addressed by the use of a standard design pattern culled from the experiences of many developers (and documented along with 20 or so other patterns in an excellent book called ‘Design Patterns’ by Gamma et. al.)

2.3. The ‘Hockey Stick’ Project - High Costs Appear Late In The Day

Figure 3 - Relative cost of fixing the same problem across a project lifecycle

The statistics shown in Figure 3 - showing the relative cost of fixing the same problem during different phases of a project lifecycle - have been available for many years, however the costs associated with late fixes are still common - especially on larger projects. Such projects often exhibit what is euphemistically known as ‘hockey stick’ behaviour, whereby all seems to be well and the project is apparently coming in on schedule, until late in the day when fundamental design errors or integration problems are revealed and the schedule goes out of the window.

Whilst not removing the possibility of such problems completely, the systematic use of OOA/D techniques such as those provided by UML can substantially reduce the chances of such errors occuring. Three factors contribute towards this:

1. OOA/D notation makes design decisions explicit
   It is extremely difficult to represent the design of a procedural program without actually writing the code - by which time any problems are embedded into application. The UML OOA/D notation offers a means by which the detailed design of an (OO) application (i.e. its classes and their inter-relationships) can be made explicit - and hence can be reviewed by more experienced staff during the design process, thereby avoiding costly mistakes. Figure two gives an example of UML in action - showing an object model. Further notations are available, however, detailed discussion is beyond the scope of this whitepaper.

   
   Figure 4 - The hockey stick project - major costs appear late in the day
   

2. A good OOA/D process will use the facilities of UML to apply consistency and completeness cross-checks
   Used with an appropriate process (i.e. work process) UML can provide cross-checks to enable designers to be very confident that the design they are proposing will actually implement the required system functionality. The reason this is possible is that there are logical ‘hooks’ between the design notations provided within UML that complement and consolidate each other, in much the same way that an architectural plan would be complemented and consolidated by its corresponding electrics and plumbing plan.
3. A good OOA/D process will use the facilities of UML to encourage code re-use
   Note also that the use of an appropriate process with UML will also encourage intra- and inter- project re-use of code because it will make the opportunities for code re-use visible, and therefore reduce the number of potential bugs in the application. This is especially true on multi-person projects where such opportunities are often lost through lack of team communication.

3. Maintenance Costs

Figures for the relative proportion of project costs that are consumed during system maintenance vary, however it is not uncommon to see estimates in the region of 70%. Reducing the cost of maintenance is therefore a vital factor in the economics of software development. In this section, I take a look at some of the reasons that underlie maintenance costs.

3.1. Traditional Software Is Inflexible and Expensive To Change

A further problem with traditional software is its lack of flexibility once it has been written. One of the major causes of this inflexibility is the ever increasing number of inter-dependencies that grow between different parts of the system.

In this respect, procedural programming languages have two main components: the data and the lines of code. The code tells the application what to do, and data provides the raw information on which to do it. The lines of code therefore become inherently dependent on the data which they use.

As systems grow in size, these dependencies become increasingly unmanageable: a change in one part of the system may well have an impact on many hundreds of other parts of the system. Introducing a small change often leads to a large number of bugs in disparate parts of a system, with all the associated costs. In effect replacing one length of metal on our suspension bridge causes problems hundreds of feet away. As each bug is fixed, yet further bugs may be introduced, and so the process continues. Eventually such systems become unmaintainable, and must be rebuilt from scratch.

Figure 5 - Code and data inter-dependencies become unmanageable in large systems

Object Oriented systems reduce the problems associated with inter-dependencies by packaging the code and the data that it uses together into objects. This localises the inter-dependencies between code and data to single objects, and hence offers substantial cost savings during software maintenance.

But this is not the whole story: Object Oriented systems go much further than this in reducing the cost of software enhancements. Object Oriented languages have built-in facilities (known as inheritance and polymorphism) to enable new objects to be added to the system perhaps years after it has been originally written, without having to change the original system at all.

Figure 6 - Object oriented systems restrict the impact of change

To see how this might work, let’s go back to our banking system example. Our account object provided facilities for: recording debits; recording credits; printing statements and calculating monthly charges. Many banks have different types of bank accounts, and whilst the crediting, debiting and printing of statements may be common to all types of account, the calculation of charges is very likely to vary.

Figure 7 - Account object template from which more specialised objects can be derived

To deal with this, Object Oriented systems enable us to define a ‘template’ objects, which outline the services provided by all accounts, and then to refine special accounts which may deviate in their implementation of specific services. The banking system will define a template Account object (providing services for crediting, debiting, printing statements and calculating charges) which will enable special refined Accounts (for example: ‘high interest savings’ accounts; ‘current’ accounts) to vary the implementation of some or all of the services. Thus, a ‘high interest savings’ account would not apply charges at all, whilst a ‘current’ account would undoubtedly apply a set of exorbitant charges for the privilege of letting us get at our own money.

Let us suppose our banking system has been built and usefully in service for a couple of years. One day, someone in the marketing department dreams up the new concept of the “save and borrow flex-account”. Needless to say, this account has a whole different approach to charges, and even allows customers to become overdrawn without first asking permission (at a price, of course).

The banking system obviously needs to be updated to deal with the new type of account. To do this, the Object Oriented developer refines a new type of account from the basic template. The ‘save and borrow flex-account’ shares the original implementation of the crediting and printing statement facilities, but redefines the services for debiting and calculating charges to take account of its individual peculiarities. The new account object thus defined is ‘plugged into’ the existing system, and hey presto, everything works as if the ‘save and borrow flex-account’ had been part of the original system in the first place.

3.2. Traditional Software Structure Doesn’t Reflect The Real World

One final problem with traditional software. Its structure (or lack of it) means that it doesn’t reflect the problem domain (real world) to which it applies. This lack of continuity between the problem domain and the software structure means that often, what seems to the user of the software to be a small change in the systems functionality frequently costs a disproportionate amount to implement.

Whilst most users would realise that turning a banking system into an aircraft maintenance system would be a costly exercise, they may be somewhat dismayed (to say the least), that adding a new type of account is going to cost half as much again as the original system.

As we have already seen (see figure 7), a good Object Oriented system, produced using the appropriate Object Oriented Analysis and Design (OOA/D) techniques, are structured such that the program code written will have a strong relationship to the real world situations it models. Rather than rewriting half of the system, adding a new account becomes a simple operation.

4. Costs Into The Future

So far, this whitepaper has argued the commercial case for Object Oriented software development by showing how it improves on the engineering deficiencies that underpin the economics of traditional software development.

As the new millennium approaches, the trends of systems development will become more and more focused on client/server and three-tier systems: enabling users to access their systems from their desktop PCs, whilst also providing the benefits offered by monolithic systems (shared data, shared facilities, greater computational power, etc.).

Figure 8 - Trying to distribute a traditional application can be nigh on impossible

Whilst developing current systems is merely uneconomic using traditional software development approaches, developing multi-tier systems can become nigh on impossible.

The building blocks provided by Object Oriented systems provide the basis by which systems may be distributed: the facilities provided by an object on one machine may be accessed via the object’s interface (its services or operations) from another machine. The object comes to the rescue by providing the building block upon which inter-machine communication can be based. In fact, although extra design work is necessary, it is interesting to note that the problem domain structure of a well analysed system (called the problem domain object model) will remain largely unchanged regardless of whether the system is implemented as a monolithic, client/server or three-tier system.

Figure 9 - Objects provide a natural mechanism on which to base distributed systems

5. The Millennium Bug

No whitepaper on software costs would be complete without at least a brief (although in this case slightly tongue-in-cheek) look at the millennium bug. As I’m sure most of the world now knows, the millennium bug is caused by systems treating dates as two-digit numbers - and consequently failing when the year turns from ‘99’ to ‘00’.

Had such systems been developed using an Object Oriented approach, the date would have been a fundamental system object, providing services to set the date value; compare dates; print the date in a certain format, etc. Even if the designer of this object had had the lack of foresight to store dates as two digits, this would have been fixed by simply modifying the internals of the date object and relinking the system (which of course used the same date object whenever a date was needed) - thus solving the whole millennium bug problem in less than half a days work - really!!

Figure 10 - The Millennium Bug is fixed in half a day!!!

6. Conclusions

This whitepaper has looked at the costs associated with software development and how an Object Oriented approach to software development can help to reduce these costs. To summarise, object oriented software development can:

• provide higher level building blocks that reduce costs by encouraging re-use and reducing the inter-dependencies with a piece of software that often underlie high maintenance costs
• help in the transfer of knowledge between more and less experienced software developers through the use of ‘patterns’ reducing the cost of learning
• provide a framework to ease the extension of system, reducing the cost of enhancements
• assist in bringing the cost of changing systems more in line with users’ expectations.

For larger projects, the use of industry standard analysis and design notation (UML) in conjunction with an appropriate development process can also reduce the cost of communication errors between analysts, designers and developers - the same notation is used by all aspects of the development team.

Some words of warning. Although Object Orientation would not be possible without programming languages that support it (C++, Java, etc.), there is much more to the commercially effective use of OO than simply changing programming languages:

• staff must undergo a fundamental change in mindset to use OO successfully, in particular ‘not invented here’ syndrome may often lead to some of the commercial benefits of OO being lost (it is often much more cost effective to buy standard objects than to build them yourself)
• OO must be used at all stages of the project lifecycle - there is little point using an OO development language at the end of a traditional analysis and/or design cycle
• management must ‘buy-in’ to the change to the OO philosophy, and in particular must set the commercial objectives of the change - the reduction of software costs - and ensure during analysis/design reviews that the appropriate decisions are being made with respect to these objectives
• migration to OO must be structured and planned to ensure its effectiveness.

There are also some tricky dilemmas to overcome: the software needs of one project may be different to the needs of the organisation as a whole - extra costs will be involved if the objects developed in one project are to be used on a cross-organisational basis; the short and long term objectives of software development are often at odds with each other - getting the project completed (on time and to budget) in the short term vs. designing in the hooks necessary for to cut down longer term enhancement costs.

Many commercial products are now jumping on the ‘object’ bandwagon. Be sure to check them all out thoroughly. If they don’t provide the facilities discussed in this paper (many don’t) then you won’t get the commercial benefits.