Simplicity in the spectrum: Identifying and overcoming overengineering

Chojnacki Krzysiek
WarsawJS

--

The following article is based on a presentation given by Przemysław Konefał WarsawJS Meetup #116.

What is Over-Engineering and What Causes It?

“Over-engineering is solving a problem that you don’t have.”

– Przemysław Konefał, WarsawJS 2024–07–10

Over-engineering happens when your solution doesn’t match the problem. It can occur in two ways:

  • Trying to solve a problem with the wrong solution
  • Applying a solution to the wrong problem

The latter is more common, which is why it’s crucial to define the problem first.

Complexity isn’t binary; it’s a spectrum from simplicity (under-engineering) to complexity (over-engineering). The best solutions are usually in the middle.

Why is it so Hard?

Business and Tech Objectives

Business and tech objectives often don’t align. Przemysław’s table illustrates this well:

Business vs Tech
 Time to market - Cost efficiency
 Risk management -  Legal compliance
 Scalability - Performance
 Security - Developer experience

Remember: tech serves business, not the other way around. This is crucial when resources are limited and trade-offs must be made.

Personal Reasons

Personal and psychological factors can also lead to over-engineering. Some examples:

  • Junior engineers trying to prove themselves
  • Developers curious about new technologies and applying them everywhere
  • Competitive team leaders trying to outshine colleagues

Knowledge Gaps

Not understanding the strengths and weaknesses of your tech stack can cause over-engineering. Creating workarounds or not using provided functionalities can lead to unnecessary complexity. Also, not knowing the codebase can result in redundant solutions.

Scope Problems

Vaguely described technical or business scope often leads to assumptions. And as the saying goes, “assumption is the mother of all disasters,” including over-engineering.

Status Quo and Working Culture/Guidelines

Both a lack of standards and blindly following outdated standards can result in suboptimal (and thus over-engineered) code.

How to Spot Over-Engineering

Przemysław provided a list of symptoms to watch out for:

Symptom and Description for each
 — Wrong abstraction
 Code is hard to read and understand, with too many abstraction layers
 — Extremely safeguarded code
 Code is protected against even the weirdest and most improbable edge cases
 — Premature optimization
 Obsessing about irrelevant metrics
 — HOW before WHY
 Many unnecessary features with unclear purpose
 — Delayed development timelines
 Focusing on unimportant features or bugs instead of providing working code

Solutions!

We’re not hopeless; there are ways to mitigate over-engineering.

  1. Scope is your ultimate guideline. Keeping an eye on the big picture and not being afraid to question the status quo can save time and help achieve business goals without over-engineering.
  2. Developing business acumen helps you adapt to a fast-changing environment and requirements, which is essential in fighting over-engineering.
  3. Keep the big picture in mind and prioritise. Tools and techniques like the Eisenhower Time Matrix, 80/20 rule, YAGNI principle, and WSJF method are useful. But remember not to over-engineer your procedures for avoiding over-engineering. Choose tools wisely according to business goals.
  4. Negotiate requirements: explore available tech or business shortcuts to simplify processes and code. However, remember to list all shortcuts so they can be addressed later.

By understanding the causes and signs of over-engineering and implementing these solutions, you can avoid unnecessary complexity and keep your projects on track.

Thank you for reading and don’t forget to visit us on WarsawJS!

--

--