Designing systems, interfaces, back end engines, databases and other system related items takes a blend of creative and technical acumen. IT professionals love to solve problems with their blended skill sets. When an algorithm is developed we sometimes even share those ideas and algorithms so it can help other systems. One case in point is my colleague Jon Taylor’s recent blog about the Observer pattern and .net event models. (Check it out of you haven’t yet-great information.) Design patterns in themselves are previous solutions that give us a solid base to develop a new algorithm from. But how many times and in how many ways have we overdesigned something?

I remember a bad decision I made at the beginning of my career in overdesign. A customer wanted a backward compatible query building wizard for their staff to use that had little technical knowledge or database understanding. However, the trick was the ‘management’ staff consistently wanted to ‘adjust’ database table and field names. The data in them wouldn’t change but the name needed to change. They were adamant about this. In coming up with a design we looked at using SQL Server ID numbers to store. This way we could recreate the same query with new names and we wouldn’t have backward compatibility issues. When built it worked great everyone had what they needed. Until a new version of SQL Server came out that instead of updating table names dropped them and re-created them. Slap the forehead time. I didn’t consider the impact or fragility change would have on the system. I focused on one direction to much.

Instead of looking to a simpler solution I went to a more complex one, or better said as an overdesigned one. I have never forgotten that lesson and I find all kinds of ways to apply it. Over the years this has turned into a philosophy and phrase ‘evolution not revolution’. Revolution is not limited to overdesigning the back end system it could be overdesigning any part of the system. In this context the concept of revolution for change is a bad one. Some of the aspects of revolution I am referring to are the destructive nature, the amount of change that has be absorbed, what can’t be changed back and the time to adjust to the changes. When your users are feeling the impact of a system revolution is this a good thing? What causes them to feel that?

 We aren’t talking about users feelings at the deployment of a system. We are talking about the users feelings over time. One example, I heard company say they couldn’t adjust the size of a banner frame for their customer because they had built it custom. It would take to many hours to change. That small issue was the start for the customer losing faith in the product and the team that created it. Eventually that team lost the business. Why? They created a revolutionary new banner frame that was great. But when the customer needed change they couldn’t accommodate efficiently and cost effectively.

When architecting we have to be able to break down a system to its critical components and work forward. We have to keep in mind that the parts of our systems need to evolve and grow. To best serve our customers we have to be diligent in evaluating if our design is evolutionary or revolutionary. Thinking of the quote ‘an ounce of prevention is worth a pound of cure’ what are some simple ways to prevent overdesign. Collaborate; working alone in a vacuum is not always a great way to a solution. One of the reasons collaboration is such a great tool for teams is someone is always looking for a simpler way. If you aren’t working with a team or before you review with the team, ask yourself am I designing to the requirements or am I trying to add value. Sometimes in trying to add value we get so excited about what the system could do we forget that the customer may have never wanted that.

Prevention begins early in the process. Understanding the workflows and business processes associated with a system is critical. Architects, testers, developers, and customers all need to be on the same page. In gathering requirements we have to dig to the deeper process to design a quality system. With an understanding of the business processes, the entire development process begins from requirements on down reflect the beginning is a base.

Realize that for many systems that have heavy interaction, users need time with the system. This is important because I am frequently surprised with the direction a customer will drive a solution over time. It is so important to consider this during design as well as critical to take the time to design. It surprises me that even today how many developers and team almost go straight to code.  Take the time to focus on the base and look for evolution. For architects and developers design patterns are great if it fits and gives your customer what they need. Consider that the only constant is change. Do you really need that whiz bang new pattern or will something simpler work better?  

Create a system that can evolve with the customers’ needs over time not revolutionize today forgetting about tomorrow.