Design Anti-Patterns and How to fix it

Design Anti-Patterns and How to fix it

In patterns and anti-patterns of software and design. Something common seems to happen with many organizations and their approach. It is simply that, regardless of best intentions to the contrary, many organizations end up following an anti-pattern of design and build. These anti-patterns start with the following thoughts:

  • Just build something that works, we will do it the right way later
  • Use software and tools I am already familiar with, instead of the best tool or choice for the job. (Kubernete fanboys anyone?)
  • We need this done yesterday. Let’s compromise quality for speed.

Unfortunately, by the time they realized they have accrued massive technical debt and lack of software entropy, many times it is too late. In some cases, they spin off a separate unit and build it the right way. Most times however, they end up with a system that is:

  • Haphazardly structured
  • Difficult to maintain
  • Spaghetti code jungle

If you are not sure this is you, ask yourself these easy questions:

  1. Can I extract a layer of my stack and replace with another with limited effort?
  2. Can I know for certain that eliminating certain verticals or domains my entire system will keep functioning
  3. Am I able to build and deploy sub sections of code and know exactly what it impacts?

If you cannot answer these questions affirmatively, I would posture you have followed an anti-pattern of design from which few have escaped. However, there is hope!

Introducing SOA Micro-Services

By starting to extract out each piece of your software that can stand alone, you can begin to get sanity and perspective. Start with something simple, say your users or comm layer, such as in the following image from the AWS Microservices approach.

By following a practice that follows SOA based architecture such as Onion, or Domain, you can begin to extract away the layers and provide an approach that makes sense for your organization and allows you to scale quickly. Ensure you also have buy-in from your leads and management, so that, as you begin to fix your structure, you don’t fall back into the habits of just getting it done. Always ask yourself the rule of thumb questions:

  1. Can I extract a layer of my stack and replace with another with limited effort?
  2. Can I know for certain that eliminating certain verticals or domains my entire system will keep functioning
  3. Am I able to build and deploy sub sections of code and know exactly what it impacts?

Please add your thoughts if any.

Leave A Comment

Your email address will not be published. Required fields are marked *