The Value of Consistent Design

Yesterday I wrote about best practices, illustrating that what may be an assumed technical design standard doesn’t fit every scenario. In a similar vein, I believe that consistency often trumps what are considered to be best practices. In this post, I’ll share some thoughts on the value of consistent design.

The “Right Way” to Solve a Problem

When I began my technical career, I had a fairly small domain of problems to solve. In my little bubble, aided by books, blog posts, and other materials generously shared by others, I assembled an informal but trustworthy set of tools and methods to use. My own budding experience and the experts whose materials I read engrained in me a loyalty for those design patterns I had come to trust, to the point that I did my best to avoid other designs that I found to be less capable than my own.

My world expanded greatly when I began offering my services to the public. Working as a technician-for-hire and later as a consultant, I found myriad ways to solve the same problem, many of which violated the best practices on which I relied. On a few occasions, I pointed out to clients why a particular architectural design or technical asset was not optimal and should be changed, and the reaction wasn’t what I expected. Back earlier in my little bubble, I had a lot of control over how things were designed, but out in the real world, implementing what arguably could be a better technical design would often require business disruption and significant cost.

The Value of Consistent Design

As a contractor or consultant, one must learn quickly (and sometimes publicly), and fortunately I learned this lesson after only a few awkward conversations: There is a tremendous amount of value in consistent design, even if that design does not comply with what most consider to be best practices. Rarely do any of us get the gift of a greenfield development project, so we’re constantly having to honor constraints and conventions that were designed by those who came before us. Whether it’s an unorthodox naming convention, an absence of surrogate keys in a data warehouse, a functional but clunky source control setup, or an unconventional data storage medium (hello there, XML!), there will be innumerable designs and conventions that seem to violate one or more of the best practices we’ve come to know. While it would be easy to criticize and insist on change, one must first consider how well the current design is meeting the needs of the business, and the possible impact of changing that design in mid-stride.

Before trying to implement a new design standard, consider the total cost of doing so. Assuming that these best practices are phased in as part of new development, the systems and support personnel now have to support at least two different designs, naming conventions, etc. Users who consume those applications or data may need to retrain to learn the old and new ways of doing things. There’s now a need to document both the legacy design and the new design, and maintain both sets of documentation. While the best practices implemented may in fact be superior to the old way of doing things, the cost in dollars, efficiency, and good will can be steep.

For the record, I’m not trying to talk anyone out of applying best practices. In fact, I’ve still got a battle-tested set of designs that I rely on when I get the opportunity to build from the ground up or reengineer a system. But when making changes to existing architectures, always consider the value of consistent design. Consistency makes a more supportable and easier-to-understand solution, and if the incumbent design patterns are working well (even outside the boundaries of typical best practices), try not to upset the apple cart.