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

Deploying a React App on AWS With Gitlab CI

Kubernetes Scheduler 101

Rule-based authorisation for your GraphQL server

Choosing a Reactive Framework for the JVM

5 Things You Need to Know to Ace the Amazon Coding Interview

Harness Your Kubernetes Cluster With k9s

Bringing Back the Barter Economy

Statistical look over React, Angular and Vue

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

Pro Pair Programming

Gravity in software

Singleton Pattern — Design Patterns

Unit testing is overkill, or it isn’t?