Good Systems Need the Open-Closed Principle

Arthur C. Clarke said that any sufficiently advanced technology is indistinguishable from magic. In the business world, lots of things look effortless but are the product of thousands of hours of work. Video conferencing depends on fiber-optic networks, server farms, and plenty of software. A notice pops up on your screen and the magic happens. We only notice when technology breaks down. Only then do we realize how much the world turns because of technology. As a project manager and technology professional, my biggest challenges are rarely technical; they're human. People's expectations often outpace the technology itself. Fortunately, people challenges share some commonalities with technology challenges, and today I want to cover an overlapping idea from object-oriented development and how to use it to address a people problem.

The Snowflake Syndrome

In enterprise technology, you run into people who have over-identified with the business and its processes. They say that their business is unique and special like a snowflake. It may be true, but even snowflakes obey the same rules of chemistry and gravity. So, when you abstract something like payroll or accounts payable, you often face fierce resistance because it differs from how the organization does things. People still need to get paid, and checks need to be deposited, so standardizing based on how most businesses operate makes sense. Unfortunately, sound, repeatable business processes often spark controversy.

For instance, if an invoice is older than 90 days, it often goes to collections. However, the CFO has a handshake deal with a client at the racquetball club, promising that invoices over 90 days won't go into collections. It is easy to write software programs to deal with the 90-day deadline. It is challenging to process all of the exceptions that crop up in the business. For many of us in technology accustomed to repeatable processes, creating numerous exceptions to an established process is maddening.

Enter the Open-Closed Principle

Fortunately, exceptions happen often enough in business that developers and project managers have created tricks to handle them. One approach is the Open-Closed Principle from object-oriented development. Simply put, the open-closed principle states an object should be open for extension but closed for modification. Using our invoice example, I will show you how this works.

Every business, medium-sized or larger, has an ERP system. These systems typically process all client billing and invoices. A customer has a record, and they can have one or many invoices. If I wanted to diagram this relationship in UML, it would look like this below.

This relationship works, and by default, when an invoice ages 90 days, it goes to collections. Since the CFO is wheeling and dealing with buddies at the racquetball club, you can create a property in the customer record called MaxInvoiceAge. If the value is zero, you must pay in advance. If the value is 365, you might have the CFO as a racquetball partner. This works fine for most cases, but what if some customers are private businesses and others are government entities?

Extending Beyond the Exceptions

The CFO can't just waive the collection fees for the sultan of some emirate who built him a recreation center. Corruption regulations require him to account for the exchange taxes and send delinquent invoices to collections after 90 days. Instead of creating a special customer object or modifying the customer object, we extend it. By refactoring our model to extend the base class rather than modify it, we make our structure resilient to the new rules.

Notice that the customer object serves as a base for ForeignGov and Domestic. The customer object is closed and cannot be modified, but the other objects inherit its properties and can have special behavior. This helps an organization establish base rules, with exceptions documented as extensions rather than chaotic one-offs that could break the entire business process. It also saves your sanity as a project manager or technology professional.

Embracing the Open-Closed Principle will not eliminate corporate exceptions, but it will keep them from breaking your systems and sanity. In short, it looks like magic, but you know the secret.

Until next time.