Sunday, March 25, 2012

Designing Software to Minimize the Cost of Change

With all the legislative and technical changes that are impacting real estate settlement software, expensive and time-consuming changes are becoming increasingly necessary. With yet another revision of the HUD-1 form on the horizon, and new MISMO data requirements for lenders set to go into effect this year, this is a good time to look at ways you can make your software more easily adaptable to change.

For those who are not as familiar with the technical aspects of creating software, perhaps an analogy could help. Consider light bulbs. The federal government and some state legislatures are considering a ban on traditional incandescent bulbs in favor of energy-saving technologies such as compact fluorescent or LED bulbs.

Imagine if a ban on incandescent bulbs required you to hire an electrician and replace every light fixture in your home. That would be very costly, and pardon the expression, but a royal pain-in-the-arse, right? Thankfully, you can just swap one type of light bulb for another without any electrical work.

The reason you can easily switch from one light bulb technology to another is because light fixtures use a well-defined socket that will accept any bulb. All long as a light bulb fits the dimensions and electrical requirements of standard household fixtures, you do not need to be concerned with the underlying technology of the bulb (except for cost perhaps, but that is another discussion entirely).

There are similar concepts in software design: loose-coupling and interfaces.

Loose-coupling means designing software in such a way that distinct pieces of functionality can be readily swapped out with little or no need to modify other parts of the application.

Interfaces are the software mechanism that allows the easier and less-costly replacement of functionality. In the case of light bulbs, the socket is the interface. In software, an interface defines how one part of an application talks to another.

Ideally, settlement software should be designed so that the implementation of anything that is subject to change (such as the HUD-1 form) is a separate component (think light bulb). The portions of the software that gather the data for the HUD-1 form should have no knowledge of the physical formatting of the form, such as sections and line numbers. The order entry portion of the software should simply pass this data to the HUD preparation component using an interface (think light bulb socket) and let the HUD piece deal with how to present the data.

Designing software in this way minimizes the cost of changes by isolating the parts of the application that change. It is relatively easy to create a new software component that takes raw data, such as settlement information, and displays or prints it in a new format.

On the flip side, when details such as HUD sections and line numbers are referenced throughout an application, the amount of software code that needs to be changed grows dramatically. Application-wide, non-isolated changes are both costly and risky.

I highly recommend that anyone responsible for designing or building software read the book Design Patterns, Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, and Vlissides (the “gang of four”). If this book is not already required reading for computer science curriculums, it should be.

Application developers need to make sure they take the time to adequately design for change. End-users need assurance from their vendors or information technology providers that they are providing change-resilient software. Doing so will save tremendous amounts of money and aggravation.