Selecting and Setting Up an OO Project
- PROJECT SUITABILITY
- PROJECT PURPOSE
- PEOPLE
- TECHNOLOGY
- TRAINING AND GETTING ADVICE
- LEGACY ISSUES
- REVIEW
This chapter is from the book
This chapter is from the book
This chapter is from the book
Your first OO project: not too big, not too small, not too important, not too unimportant. What does this mean? The project should either deliver value directly or show you how the company will react to object technology. It must fit the history, temperament, and capabilities of the company.
Consider two extremes, each faulty. On one extreme is a small, test project with just two people. Such a project will be fine for those two people; it will improve their résumés. But it is unlikely to show whether the company ought to use object technology because it will not characterize your situation. People are unlikely to pay attention to the results. On the other extreme is a company-critical project as a first project. It can be done, but the risks are high, so you must take special precautions.
Your first OO project should be selected to reveal how the technology will be used and what problems you will encounter. It should be important enough to be noticed, but not so critical that the risks are deadly. Because all rules have exceptions, here are four complementary guidelines:
A project designed to get as much done as possible quickly should consist of two people, to avoid the communications difficulties that accompany OO projects.
A project to investigate the technology should have at least four people on it to reveal some of the communications issues that accompany OO projects.
A project to decide whether to shift the entire company to object technology must be serious enough that completion, or failure to complete, is a significant event to the company. Otherwise, its success or failure will be inconclusive.
A project, the failure of which would be disastrous, needs special precautions and backup measures. It should not be allowed to fail because of neglect, poor management, or insufficient funds. That would be a triple blow: the failure of the project, the failure of the management involved, and a failure to master the technology.
The best first step is to set up the project well. The next sections go over topics you should address before you get underway: selection of a suitable project and establishing its purpose; selection of staff, language, and tools; evaluation of the need for training and advice; and legacy issues.
PROJECT SUITABILITY
Judging by the project histories I have collected, project success is not linked to "suitability to object technology." OO projects that did not appear naturally suited to object technology have been successful (see the Brook-lyn Union Gas story in Chapter 2), and "naturally suitable" projects have failed from obviously poor management. Yet it is still useful to characterize whether a project is naturally suited to object technology. I consider a project more naturally suited to OO if the following apply:
The system will be extended by variations on a theme.
Objects obviously give a significantly simplified program structure.
The design relies on memory-management features of the OO language.
Suitability becomes relevant in answering the far more important question: How soon will the new technology pay for itself? A simplified program structure reduces the cost of maintenance. OO mechanisms allow variations on a theme to be added by programming just the differences, which creates a dramatic cost savings.
Variations on a Theme
Certain types of programs grow internally in similar ways. The simplest example is a drawing program: All the shapes need to be created, sized, moved, and colored, although each is done in a slightly different way (think of polymorphism—see Chapter 1). The program evolves by programming the simple shapes first. Over time, you add the more complicated shapes, taking advantage of the existing program parts.
Rapid variation provides a critical competitive edge. For example, rapidly varied sales promotions and rapid response to competitors' promotions make promotion modeling a natural for object technology. Finance companies compete on creation and variation of financial instruments. Insurance companies compete on slight variations in target population, insurables, benefits, payments, and so on. If you can identify critical themes in your business that vary rapidly, you have found the place where object technology can pay for itself the quickest.
Simplified Program Structure
Almost every program can benefit to some extent from being packaged around classes. Simulation of physical systems is an obvious candidate. In a traffic simulation, it makes sense to have program elements centered around cars, roads, lights, and the like.
User-interface programs of all sorts benefit from attaching program logic to the objects on the screen. Pert charts, computer-aided design (CAD) programs, graphical displays of train schedules, and routing programs are examples.
Sometimes the data being used within the program is very diverse: Multimedia programs manipulate text, voice, shapes, and video streams; geological systems manipulate seismic data, pressure readings, and spectrographic data. These programs are a natural fit with object technology because it is most convenient to co-locate all the program parts that manipulate a particular data type.
Repeatedly, people report that their OO programs better localize design decisions, making it easier for the program to evolve (see Tom Morgan's Eyewitness Account in Chapter 2). Is this, perhaps, because they were able to design the system from scratch, with the benefit of hindsight and advancements in the software field? My experience is that few IS developers are trained in encapsulation. Many students have commented during object-oriented training that encapsulation considerations are new to them. They need classroom training, plus the enforcement from the OO language, to change their design habits.
Memory Management Features
Occasionally you will encounter a program that can take dramatic advantage of one particular language mechanism. One project I encountered was to implement a communications protocol; it paid for the use of C++ simply by its ability to handle data buffers. A message arriving at a network point gets put into a buffer and passed across different protocol layers. Allocating, handling, and freeing those buffers is both prone to error and hard to fix. The project leader said that the constructors and destructors of C++ simplified programming enough to pay for the entire move to object technology. Although it is unusual, you may recognize when you are in such a situation.
What Is Not Suited?
It is hard to answer, "What is not suited to object technology?" Recall that object technology is fundamentally a program-packaging technology that permits a continuum of function-only and function-plus-data packages. It is therefore not inappropriate to any particular type of system. Objects have been used in oscilloscopes, payroll systems, CAD systems, user interfaces, and banking and insurance systems.
The question really is, "When is it not worth the cost to retrain your development staff in OO?" This is easier to answer. If your system serves its purpose, keep using it and avoid the training costs and general agony of shifting to a new technology. The average CRUD (create/retrieve/update/ delete) application, which reads and writes data to a database, is nicely served by current application generators. Some CRUD systems are being rewritten in objects, but many organizations choose not to make the shift just for this kind of application.
If your current way of building software is causing you difficulties, try to find a project with one of the natural affinities to object technology, as just described. Aim to offset the training costs with a gain in time-to-market or maintainability.
Make sure the system is worth the cost of training the people.