We return to pick up a couple of new patterns.  In this episode, we look at the keep it simple pattern and how to apply it to architecture.  It is a pattern that we often overlook.  However, it is an essential piece of many successful solutions.  It is the heart of our desire to break complex things down into small pieces we can tackle.

The Keep It Simple Pattern Defined

We run into this pattern, or mentions of it, in many areas of life.  Software architecture is no exception.  When we face a decision to build a complex solution or a simpler one, we want to choose simplicity.  Yes, complex solutions can be fun to tackle and impressive.  However, they have more room for mistakes and a lower chance of success.

That combination of low percentage success and high percentage for mistakes combines into a challenging anti-pattern.  Therefore, we use the keep it simple pattern to avoid that trap.  This approach is defined by a desire to keep every decision as direct and straightforward as possible.  While the solution may not be simple, it is an attempt at the lowest common denominator approach to solving a problem.

Applying The Pattern

We have seen numerous ways to implement this pattern in our look at patterns and anti-patterns.  First, we break down our solution into smaller problems.  Then, we build solutions a bit at a time and put them together for the overall solution.  The pattern is to avoid adding complexity unless we are forced into it.  Clever solutions can impress others.  However, they also are not helpful as a foundational piece for a larger solution.  We want to build solid, stable, and reliable bricks to craft our solution’s strong foundation.

Challenges

There is a sort of boredom or lack of excitement from simple solutions.  They do not challenge us as much as big hairy audacious obstacles.  We must remember that the goal in building a solution is not to make it fun or challenging for the implementors.  The goal is to provide a solution that satisfies the customer.  When we focus on the problem and a direct solution, we are more likely to apply this pattern.

Rob Broadhead

Rob is a founder of, and frequent contributor to, Develpreneur. This includes the Building Better Developers podcast. He is also a lifetime learner as a developer, designer, and manager of software solutions. Rob is the founder of RB Consulting and has managed to author a book about his family experiences and a few about becoming a better developer. In his free time, he stays busy raising five children (although they have grown into adults). When he has a chance to breathe, he is on the ice playing hockey to relax or working on his ballroom dance skills.

Leave a Reply