The Plethora Of Prodigal Patterns

"Make everything as simple as possible, but not simpler"

Albert Einstein

With all of the software design patterns available to developers, I think that we sometimes lose focus of the pragmatic development approach: Write code that works.

Don’t get me wrong, I do believe that software patterns are a very valuable tool in the software developers repertoire.  When implemented correctly they provide enhancements in maintainability, flexibility, and typically result in cleaner code.  After all, patterns are exactly what the name implies: a standard and effective way to implement common objectives.

However, the misuse of patterns can lead to significant problems as well.  The unnecessary overuse of patterns can result in the following:

1. Code Complexity

“Every time you put extra stuff into your code to make it more flexible, you are usually adding more complexity.” - Martin Fowler

Unless there is a need to introduce complexity, it is simply a bad development practice.  Complexity has many side effects.  If not introduced with care, complexity can lead to problems with testability and maintainability, which is the fundamental opposite of the compelling reasons to implementing design patterns.

2. Unnecessary Code

If a developer sets out to implement patterns before fully understanding the requirements, extra code can be introduced that does not serve a real purpose in the application.  When we get into this over-creative zone, we tend to anticipate what we think that the application will need rather than coding to the specifications.  This leads to both increased complexity and increased maintainability, as well as losing sight of the real goals of the implementation.

3. Paralysis by Analysis

When trying to predetermine patterns from the start or a development project, a developer can often get caught up in a state of perpetual design analysis.  This period of paralysis is bad for two reasons.  It typically incurs a significant cost in time and it keeps the developer from concentrating on and implementing the actual requirements of the project.

4. Cost of Development

All of the above lead to an increased amount if time spent on design that is not spent on writing code to satisfy the requirements.  As professional developers, this is the ultimate goal: To write code on time and on target.

Patterns should be implemented when a reason becomes evident.  This is the essence of refactoring.

“Code refactoring is the process of changing a computer program's internal structure without modifying its external behavior or existing functionality. This is usually done to improve code readability, simplify code structure, change code to adhere to a given programming paradigm, improve maintainability, or improve extensibility.” - Wikipedia

If your development process includes proper unit testing practices, refactoring to an apparent design pattern is easily manageable while still maintaining the original purpose and validity of the implementation.

Good software design is an evolutionary process.  In my opinion, a developer should start with one goal in mind: to meet the needs of the customer.  This is really the only metric that matters.  Sure, we all want to write “beautiful” code and be academic developers, but the needs of the customer must come first.  The rest will come in due course.  To be a successful developer I think that we need to remember the basics: start simple and write code that works.