Tag Archives: accidental complexity


The charm of complication

(or the Attraction for Complexity) There is a very common tendency in computer science and it is to complicate solutions. This complication is often referred as incidental/accidental complexity i.e. anything we coders/designers do to make more complex a simple matter. Some times this is called over engineering and stems from the best intentions :

  1. Attraction to Complexity: there’s often a misconception that more complex solutions are inherently better or more sophisticated. This can lead to choosing complicated approaches over simpler, more effective ones.
  2. Technological Enthusiasm: developers might be eager to try out new technologies, patterns, or architectures. While innovation is important, using new tech for its own sake can lead to unnecessary complexity.
  3. Anticipating Future Needs: developers may try to build solutions that are overly flexible to accommodate potential future requirements. This often leads to complex designs that are not needed for the current scope of the project.
  4. Lack of Experience or Misjudgment: less experienced developers might not yet have the insight to choose the simplest effective solution, while even seasoned developers can sometimes overestimate what’s necessary for a project.
  5. Avoiding Refactoring: In an attempt to avoid refactoring in the future, developers might add layers of abstraction or additional features they think might be needed later, resulting in over-engineered solutions.
  6. Miscommunication or Lack of Clear Requirements: without clear requirements or effective communication within a team, developers might make assumptions about what’s needed, leading to solutions that are more complex than necessary.
  7. Premature Optimization: trying to optimize every aspect of a solution from the beginning can lead to complexity. The adage “premature optimization is the root of all evil” highlights the pitfalls of optimizing before it’s clear that performance is an issue.
  8. Unclear Problem Definition: not fully understanding the problem that needs to be solved can result in solutions that are more complicated than needed. A clear problem definition is essential for a simple and effective solution.
  9. Personal Preference or Style: sometimes, the preference for certain coding styles, architectures, or patterns can lead to more complex solutions, even if simpler alternatives would suffice.
  10. Fear of Under-Engineering: there can be a fear of delivering a solution that appears under-engineered or too simplistic, leading to adding unnecessary features or layers of abstraction.

Croatia islands

Jan 2020 reading list


Spotify Engineering culture : https://medium.com/productmanagement101/spotify-squad-framework-part-i-8f74bcfcd761

QUIC : https://quicwg.org/base-drafts/draft-ietf-quic-http.html

Teamcity REST API : https://confluence.jetbrains.com/display/TCD10/REST+API

Object-Oriented Programming — The Trillion Dollar Disaster https://medium.com/better-programming/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7

Stop using classes in JS : https://medium.com/javascript-in-plain-english/please-stop-using-classes-in-javascript-and-become-a-better-developer-a185c9fbede1

Interesting read about latency and how 99% Quantile may not be enough : https://bravenewgeek.com/everything-you-know-about-latency-is-wrong/


What’s wrong with word “simple” ? ( on over engineering code )

Over engineering code is a common plague that leads to a number of unwanted side effects in your software ranch. Consider it just a form of bad software design.

This post does not want to be an exhaustive guide on over engineering but with the help of many quotes  from different sources, I’ll try to summarize the impacts, when you can have evidence of over engineered code and the causes (to try to avoid them).


  • unneccessary complexity => less agility in software
  • more code, more bugs
  • more code, more unit tests, more development time
  • performance impacts
  • longer catch up time for newcomers
  • difficult maintenance, fixing bugs requires more time than it should
  • small changes require big efforts and are prone to having many bugs
  • unwanted features are present even though there is not reference in requirements/backlogs and so you have to maintain them even if they are not used
  • false perception of complexity in the code that leads to over inflated estimates for fixes, changes.
  • extending an over engineered project makes extensions more complex than necessary
  • dismantling of over engineered code takes way longer than it took to over engineer it
  • Need for complete rewrite over time to reduce unneeded complexity when maintenance times become higher than rewrite time This is an interesting topic itself and needs a separate post)

Concrete symptons  of over engineered code

Really difficult here to point out some easy and simple guidelines to recognize over engineered code. Often it is an individual perception and this does not help. I’ll try :

  • When a well experienced coder, which has been working on that piece of code for at least an year, still takes way more than necessary/affordable to figure out where/how a specific feature works. I’m trying to find a better explanation for this concept
  • In code : using a factory even if it is making type of objects
  • In code : use an interface even if it is actually going to be implemented by just one class
  • From PrematureGeneralization

“This is really going to be a clean framework. I’ll make an abstract class out of this part so that folks can subclass it later, and I’ll put in a bunch of well-commented overridable hooks in the concrete subclasses so that folks can use them as templates, and just in case somebody ever needs to build special debug subclasses, I’ll put in extra stubs over there (somebody will thank me for ’em one of these days). Yeah, this is really going to be neat.Thus is bloated software produced when our artistic sense gets the better of us. — DaveSmith “

Some other signs of over engineering taken from stackoverflow :

One very strong warning sign of over engineering is when everything goes through so much indirection that it’s hard to find the piece of code that actually implements some concrete, domain-level piece of functionality. If you find that most of your functions do very little concrete work and just call other virtual functions, you may have a problem.


[..] Make factories where the factories make more then one type of object. Use dependency injection, where it immediately shows benefits. Make interfaces that are actually going to be implemented by more then one class [..] What I see too often in “true OO” is that advanced techniques are used to solve really simple problems in an overly complex way [..]

Causes of over engineering :

Accidental vs essential complexity

Interesting article, some really good points :

Software should behave predictably and accomplish its goals without too many surprises (that is, outages in production). The number of surprises directly correlates with the amount of unnecessary complexity found in a project. It’s therefore crucial to think about accidental complexity and essential complexity:

Accidental complexity relates to problems which engineers create and can fix, [whereas] essential complexity is caused by the problem to be solved, and nothing can remove it
— Fred Brooks in his seminal “No Silver Bullet” essay

Another interesting point on when a coder start to write unnecessary code :

Boredom is good precursor to over-engineered code. I’ll admit, when I got my first job, I felt so underutilized. I was just bored. And when I got bored, I wrote code. Not just any code — CATHEDRALS OF CODE.

No seriously, I had a mental picture of my code and abstractions as large towers with golden jutting spires, flying buttresses of glassy onyx, a wonderful vault supporting by arched domes topped with beautiful geometrical tracery, etc etc etc.

It was really fascinating to see the patterns working together for myself, but in retrospect, I am completely ashamed of the ungodly mess I left behind.

If you’re writing your own frameworks and DSLs code to while away the less stimulating hours at work, just stop. Time is better spent reading Wards Wiki, or writing an open source book, or you may just want to ask management for more work.

Some theory on why/when over engineering happens

  • Second system effect : you wrote a first good, simple, performant version of a product and it is getting traction so you decide to write 2.0 version of it which does everything.
  • feature creep : you just keep adding features that are used by less than 1 % of the user base/use cases.
  • inner-platform effect : you are making your system so customizable to become a replica of the features provided by the sw component of dev environment you are using.

Notes on over engineering : https://blog.matt-rickard.com/p/stop-overengineering

Avoid unnecessary abstractions (and some other usefull info) : Techniques to avoid over engineering : https://betterprogramming.pub/3-tips-to-adopt-a-simplicity-mindset-when-designing-software-711b95328062

Beware of complicated solutions (that someone was paid to find) @ntaleb

I’m still working on this point : here are some  references to interesting concepts

The KISS principle

YAGNI : Your Arent Gonna Need It

DRY : Don’t repeat yourself

Simplicity is a prerequisite for reliability