#30-Follow The Open-Closed Principle

In order to embrace change, as agile says we must, we must make sure that changes to the system going forward do not create excessive waste and/or delays.  Part of how we can do this is to follow good principles, such as the Open-Closed Principle.  This episode will explain this principle, and what it means.

Transcript

Follow the Open-Closed Principle

A major tenet of Agile and Lean is the reduction/elimination of waste.  One way to do this is to adhere to best-practices, standardized work, and strong principles.

Ivar Jacobson, a revered computer scientist of long standing, once said: 

"All software entities change during their life cycle, and this must be borne in mind when developing systems which are expected to last longer than the first version. A design principle which helps you with long lasting software is the OCP (Open-Closed Principle)."

Long-lasting systems continue to deliver value as they age, meaning that the resources initially expended to create them continue to deliver a return on investment.  Failing this, that expenditure represents some degree of waste.

The Open-Closed Principle that Jacobsen referred to comes from another mavin of systems development, Bertrand Meyer. It states: 

"Software entities (classes, modules, functions, and so on) should be open for extension, but closed for modification."  

What does this mean?  

• "Open for Extension" means that the system can have behavior added to it over time.  
• "Closed for Modification" means that when this happens, it is not necessary to alter the work of the past.  It retains its value as it is.

Put another way, one aspect of "a well-designed system" is that it allows new features of value to be added to it without requiring wasteful effort to maintain the previous features.  Add, don't change.

Is this always possible?  No.  But principles are aspirational, they guide our decisions because they inform what we should strive for in the hopes that we will achieve them most of the time.  When we cannot, we should at least know that this has happened because it represents a risk that should be visible to all concerned.

A good example from daily life is the principle of honesty.  I try to be honest as much as I can, I always think about it when making decisions on what to say and how to behave.  Does that mean I always tell the brutal truth to everyone no matter what?  If course not.  I would not be a person anyone could live with if I did.  But I always know that when don't tell the absolute truth, I run the risk of losing the trust of others or misleading them into harm.

Principles also inform our actions moving forward.  For example, here is a best practice: 

If the team has inherited legacy code that does not follow the OCP (which is typical), and they are tasked with adding new capability to it, then the guidance would suggest that the system must be refactored first to make it possible to add the desired new capability as a second step.  This is called "refactoring to the open-closed" and should be taken into account when planning and budgeting for the work in question. It becomes a standard.

As a project manager, when discussing upcoming work to add a new capability you should always ask “is the system currently open-closed to this change?”  If it is not, then refactoring should be expected when estimating the time for the work.

The best way for developers to learn to design in an open-closed way going forward is to study the design patterns, because each of them follows this principle in a different way, under various circumstances that require that new behavior be added without changing old behavior.  Knowing them also helps us identify how to refactor legacy code because we will know specifically how to reshape it and how it should look when we are done.

There are other principles like OCP, and they all have important wisdom to confer.  I will cover them in future weeks.