Over-engineering examples in Code

Some over-engineered examples may harm your code quality.

Always ask yourself “how many times will we want to go there again?”. If the answer is “once”, “sometimes”, or “not sure”, take the shorter route please 🙏

Automate non-repeated tasks that can be done in a few minutes

It’s a common mistake that every developer has made before. Developers tend to jump into the solution mode to automate everything without evaluating the return on investment (ROI).

Pro Tips:

• Learn “The Builder’s Trap”
• Think about Opportunity Cost
• Think about Maintainence Cost
• Learn “Depalyed Automation”
• Be comfortable to keep the process manual or semi-auto for a while

Unnecessary abstractions

We need to create a base class, and let subclasses override methods a, b, c, etc. This was a common convo when we were in college. If you only have 2 types of variations, can we just leave them as is?

Pro Tips:

• Don’t be fooled by DRY principle
• Avoid premature optimisation
• Wrong abstraction is worse than duplication

Over use DRY

Apply “Don’t Repeat Yourself” (DRY) too early and too narrowly without considering its benefits.

Pro Tips:

• Learn “The Rule of Three”
• Be comfortable with some duplications.

Over use design patterns

Try to apply design patterns after reading “The Gang of Four” without a deep understanding of the benefits.

Pro Tips:

• Do you really need to adopt a factory pattern to create instances?
• Does Decorator Pattern fit your requirements?
• Is your code base junior friendly?

Wrap a library

Wrappers are useful, but they’re easily overused. Do you really need to wrap aws-sdk or winston into an internal library? Or have a package for common utils? Please don’t, unless you have a clear view of what you are trying to achieve, otherwise, just use the library as is.

Pro Tips:

• aws-sdk is awesome. Just use it.
• Are you coding for delivering features or enabling for feature teams?
• Does your work align with your team vision?

Never underestimate the cost of the shell

Let’s say you have a lambda function that does one simple task, e.g., fetch a given url and log its status code. Imagine a world where you add more than 10 config files: git ignore, package, ci/cd, test lib, e2e test lib, compiler, prettier, lint, husky, docker, read me, etc. Is it a still worth doing so? or it can sit inside your modular monolithic service?

Pro Tips:

• Is this repeated enough to cover your setup costs?
• Does your system architecture align with your organisation chart?
• Have you considered the Return of Investment (ROI)?

A quick recap, these overengineering examples fall into 2 buckets:

Wrong Abstraction

• Try to solve problems in a generic matter
• Premature abstractions
• Wrap libraries

Unnecessary Work

• Early automation
• Solve problems you don’t have