Keys to a Successful Object-Oriented Project

Best practices are the rage in software development project management. Rather than marching through a life-cycle methodology, a manager can create an environment of "controlled chaos", combining the ability to react quickly to changing requirements and markets with the discipline provided by best practices to ensure the project is not far off track. This brief emphasizes best practices for projects using object-oriented (O-O) tools and languages, although several of the practices apply generally. This brief intentionally omits the obvious keys to success that apply to all projects, such as

  • Involve end users
  • Secure management support
  • Produce a clear and specific statement of requirements
  • Plan
  • Manage risk

Without these, other practices are of marginal value at best. There are many, many other best practices; those available from Christine Comaford and Steve McConnell are highly recommended (and cheap!).

The Envelope, Please

Without further delay, the keys to a successful object-oriented project, in no particular order, are

Define Success

As soon as there is more than one person on a project, there is a chance that not everyone has the same idea of success. Specify success criteria early and refine them as the project progresses. You must also realize this is not a mission statement. It is one or more things you can measure about how the team completed the mission. Some possible success criteria are

  • On-time delivery of all high- and medium-priority features
  • Delivery of all high-priority features within ten percent of budget
  • Initial defect report rate of fewer than five per week
  • Creation of a reusable domain framework
  • Creation of a reusable technical framework
  • Productivity increase of 25 percent for the second phase of the project

Remember, you define success within the context of the culture of your organization, many of which are not progressive enough to appreciate the value of all these criteria. Choose your success criteria accordingly. Also, don't be afraid to choose multiple criteria, but if you do, prioritize them.

Define All Roles

The roles on O-O projects are more-or-less a superset of those on other projects. Some of the overlapping roles, such as user interface designer and database architect, change little, if any, in the move to O-O. Many other roles, however, are new or changed, such as

  • Business Analyst, who should be fluent in Use Cases
  • System Architect, who may need to add distributed object or object database (ODBMS) technology to his or her repertoire
  • System Designer, who should be fluent in all O-O modeling techniques and processes, such as CRC, UML/OMT and Use Cases.
  • Framework Designer, who identifies patterns in the static and dynamic relationships between objects and understands how to structure code to exploit them.
  • Framework Coder, who fills in the lowest level of details in implementing all the classes for a framework. This is a software engineering role requiring a very good understanding of data structures, algorithms and the programming language in use.
  • Application Designer, who defines the user interface and program flow, identifies the frameworks that can be leveraged in fulfilling the requirements of an application and specifies the new application-specific objects and frameworks needed.
  • Application Coder, who creates the actual application.
  • Tester, who may or may not have a framework/application specialty, depending on whether the framework designer/coder teams are responsible for their own testing. Framework testers must be able to write code themselves. Testers must be well-versed in O-O modeling, too.
  • Librarian, who makes sure all the work is maintained in a repository and is readily available for reuse and review.

Match Skill Sets to Roles

Unless you have a team of clones, do not simply divide up the work in the project to spread around. This advice, while always good, is especially poignant for object-oriented projects because there is such a broad range of O-O skills, and because mentoring is such an important mode of knowledge transfer. For example, beginning O-O-ers are most productive assembling solutions from frameworks already created by veterans. They learn the programming language, but also a great deal about more advanced programming practices by seeing how the veterans have written their code.

A common mistake is to put all the most talented and experienced developers together in the frameworks group. While there is no doubt that this group will tackle the most demanding tasks at the most minute level of technical detail, application development is not without its technical challenges. Testing, when done right, requires a great deal of technical expertise as well. Spreading around the technical ability increases the likelihood of getting high quality, high productivity work on all aspects of the project.

Finally, don't skimp on professional training and mentoring, but be certain it's done in a timely manner. Don't send someone to a five-day intensive course on OMT modeling because you might want them to be a designer "soon". Plan for the transitions of personnel to new roles and schedule training accordingly.

Model Multiple System Views

First, if you are working on a moderately sized project and aren't modeling, you're toast-on-a-stick. You'll long for the spaghetti produced using structured languages after you have a look at the disgusting dish that is object-oriented code written on the fly. The greatest benefit of object-oriented development is the richness of the modeling languages. Use all the different diagram types (static, dynamic, event, state), and use them at different levels of abstraction by partitioning groups of objects into packages. Also, do not be afraid to use structured analysis models where they make sense. If at some level of abstraction the system can be naturally modeled using a data flow diagram, create one. It will advance the understanding of the system that you and others have, and that's what modeling is all about.

Do not forget that your models are ideal candidates for reuse. In fact, reuse at the model level is far more powerful than reuse at the code class level.

Create Frameworks

Frameworks in coding are conceptually similar to packages in modeling, in that they consist of a group of related objects or frameworks. They provide a set of pre-wired interactions among objects. Unlike packages, however, frameworks are not intended to hide the details of the constituents. Those details are still available to clients that need to manipulate them.

Leveraging a set of well-written, robust frameworks provides the productivity gains reported by the most successful object-oriented projects. Frameworks provide a tremendous amount of functionality to a programmer with very little manipulation, which is exactly what productivity is.

Don't Short Change Database Access

Database access is still part of object-oriented applications. While frameworks such as JDBC (Java), OLE DB/DAO (ActiveX) and dbtools (C++) standardize and simplify access to data, database access still accounts for a significant portion of the design and coding effort. Do not neglect this when scheduling, and beware the silver bullets. Even object databases (ODBMS), which alleviate a tremendous amount of the coding effort, do not eliminate the effort of designing transactions and integrity rules.

Don't Assume Objects Mean Distributed Objects

Supporting distributed objects is not a simple step from object-oriented design and coding. If you must support distributed objects, do not assume it will be a slam dunk. Account for the risk and do early feasibility tests to confirm architectural choices. If you don't have to support distributed objects, don't kill yourself trying to include them because they're cool or "just a small incremental effort". Distributed object technology is becoming more powerful and easy to use; if you can wait until it's a requirement, you may be saving yourself a lot of unnecessary grief.

Explore and Confirm Feasibility

Software development is a process of refinement. That process is never linear. Don't simply accept that, embrace it. Let developers explore new methods without betting the project on their success. Force them to confirm the feasibility of any way of doing things with which your team lacks experience. The combination provides a risk-managed way to advance the state-of-the-art within your shop, enabling solutions that otherwise would not be possible.

Define Frequent Visible Milestones

One of the side effects of creating frameworks in a rich modeling environment is the temptation to over-generalize and over-refine. Frequent milestones force commitment to delivery of something, so there is some urgency to reaching points of stability. Of course, the milestones also help you confirm that the project is on track from an external (feature) perspective.

Store Everything in a Searchable, Versioned Repository

Ho-hum, this is pretty anti-climactic. Except that if you don't have a repository, a significant part of your project walks out the door every time a developer leaves the company (or leaves your team, for that matter). Starting with your first two-page Word document, put everything under source control (at least).

For the sake of trying not to "leak" knowledge, you should also provide discussion group software to use in lieu of e-mail. First, this makes discussions public, so knowledge is shared. Second, it's much easier to archive, version and search. Notes is nice, but even newsgroups will do the job.

Copyright © 1996 Scott Nichol.
4-Dec-96