Modern Software Over-Engineering Mistakes

1. Engineering is more clever than Business

We think you have everything under control — But we have no clue whats headed our way. Image courtesy and

TL;DR — The House (Business) Always Wins

2. Reusable Business Functionality

TL;DR — Prefer Isolating Actions than Combining

3. Everything is Generic

  • Want to connect to a database? Lets write a Generic Adapter
  • Query that database? Generic Query
  • Pass it some params? Generic Params
  • Build those params? Generic Builder
  • Map the response? Generic Data Mapper
  • Handle the user request? Generic Request
  • Execute the whole thing? Generic Executor
  • and so on and so on
Whats’s the perfect abstraction? Image courtesy

TL;DR — Duplication is better than the wrong abstraction

4. Shallow Wrappers

TL;DR — Wrappers are an exception, not the norm. Don’t wrap good libraries for the sake of wrapping

5. Applying Quality like a Tool

TL;DR — Always take a step back and look at the macro picture

5.1. Sandwich Layers

Sandwich Layers in 2000
Sandwich layers in 2016 with SOLID

TL;DR — Concepts need shift in Mindset. Cannot be applied blindly like tools.

6. Overzealous Adopter Syndrome

TL;DR — TL;DRs should not be used everywhere

7. <X>–ity

  • Configurability
  • Security
  • Scalability
  • Maintainability
  • Extensibility

TL;DR — Don’t let <X>-ities go unchallenged. Clearly define and evaluate the Scenario/Story/Need/Usage.

8. In House “Inventions”

  • In-house libraries (HTTP, mini ORM/ODM, Caching, Config, etc)
  • In-house frameworks (CMS, Event Streaming, Concurrency, Background Jobs, etc)
  • In-house tools (Buildchains, Deployment tools, etc)
  • It takes a lot of skills and deep understanding of the problem domain. A “Service runner” library needs expertise of how daemons work, process management, I/O redirection, PID files and so on. A CMS is not just about rendering fields with a datatype — it has inter-field dependencies, validations, wizards, generic renderers and so on. Even a simple “retry” library is not so simple.
  • There is a constant effort required to keeping this going. Even a tiny open source library takes a lot of time to maintain.
  • If you open source it, nobody cares. Except the original starters and people paid to work on it.
  • The original starters will eventually move away with the “Inventor of X” tag in their résumé.
  • Contributing to existing frameworks takes up more time NOW. But creating an “invention” takes up considerably more time going forward.

TL;DR — Reuse. Fork. Contribute. Reconsider.

9. Following the Status Quo

Image courtesy

TL;DR — Refactoring is part of each and every story. No code is untouchable

10. Bad Estimation

TL;DR — Bad Estimation destroys Quality even before a single line of code is written

Simpleton, CI/CD Platformer at, ex-ThoughtWorker, Full stack engineer, Hack Java/Node/Frontend/Ruby/Docker/OSS, Practice XP/KISS/Lean

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

What I want (and don’t want) to see on your resume

Metadata Update Performance in File Systems

Infrequent Contributors

An Overview of AWS Organizations

Estimating Velocity for Iterations in Agile

Joyent CoPilot: Bringing Application Awareness to Cloud Infrastructure. Part IV

GDE community highlight: Nishu Goel

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


Simpleton, CI/CD Platformer at, ex-ThoughtWorker, Full stack engineer, Hack Java/Node/Frontend/Ruby/Docker/OSS, Practice XP/KISS/Lean

More from Medium

Why Software Engineers Over-engineer?

Fairy Tales, and the Implications of Immutability

Why Do Developers Hate Meetings?

The 9 Ways to Ensure You Are Unit Testing The Right Way

The 9 Ways To Ensure You Are Testing The Right Way