Working in the software industry for quite a while now, I am repeatedly surprised by how people keep making one basic mistake over and over again. Admittedly, I have probably made that mistake myself more than once in the past. This mistake I am talking about is over-engineering and it poses a serious problem for productivity, motivation and quality in software that is often overlooked.

What makes the problem of over-engineering especially difficult to deal with, is that it is usually caused by experienced and senior developers. What I have personally noticed is that with increased seniority, developers tend to over-complicate matters and become paranoid about the simplest things. This in turns triggers a whole lot of problems.

Problem 1 - Lack of Productivity

Most importantly, a culture of over-engineering software blocks progress and productivity and is the reason why especially larger organizations struggle with getting things done. While most organizations claim to "be agile", the practice of over-engineering counteracts all agility and is its natural enemy.

Over-engineering is antithetical to being agile.

Problem 2 - Lack of Motivation

Another threat posed by over-engineering is that it very often causes Analysis Paralysis. While this also affects productivity, it is doubly harmful to a project or feature because of its psychological impact. By over-engineering, an initially trivial feature gets blown out of proportion to such an extent that, as a result, developers neither dare or even can take responsibility for its success or failure. So, instead of giving developers the possibility of tackling a problem and creating value for the company, we have now created a minefield that nobody dares to touch any more.

Problem 3 - Lack of Quality

This seems counterintuitive at first, but if you think about it actually becomes an obvious consequence of over-engineering software. A pragmatic approach and solution to a problem automatically brings a very focused approach with it. By over-complicating problems, building frameworks for trivial things or trying to foresee every possible future requirement, this focus is lost, which directly impacts quality. Also, writing less code, almost always means less bugs. It's easier to ensure quality and test your software, when you focus on its basic functionality.

Solution - YAGNI

While all kinds of acronyms are usually very popular among software developers, this is one that way too few know about: YAGNI - You Aren't Gonna Need It!.

Let me state an observation I have made over many years: Every feature a team implements needs rework anyway. I haven't seen that happen any other way yet, so far in my career. So why not go with your basic and actual requirements first, implement those and iterate later (you could probably call that agile development ;-)). Ironically, that's what a lot of teams and developers think they are doing, while in fact most of the time things get blown out of proportion and made way more difficult than they should me.

So if the next time someone steps in during a planning sessions and asks the "what if ... question" (e.g. what if X happens, what if we have to support Y in the future, ...) think of - or even better: be - YAGNI Batman!

Simply think about it like this:

• Currently you don't have the feature in question at all.
• That's why you are planning it right now.
• So create value first by actually shipping.
• Iterate later.
• Probably keep your "what ifs" in a backlog and evaluate from time to time if it makes sense to actual implement them.
• But don't try to foresee everything and solve every "what if" upfront - YAGNI!

You Aren’t Gonna Need It! Trust me!