Understanding Overengineering

Tech professionals tend to like clever and powerful solutions. Software engineers take pride in using their logical brains to build complex and powerful software solutions. In some cases, this tendency can actually go too far and cause damage to a project. This issue is commonly known as overengineering.

Why is overengineering a problem?

Overengineering is defined as making a solution far more complex, feature-rich or high-quality than is actually required. Going overboard with these things is not free. It costs more resources than needed. Time, money and energy spent on unnecessary bells and whistles could have been directed towards other, more fruitful purposes.

How can we detect overengineering?

As with many aspects of life, awareness is the first step towards improvement. While there is no golden way of detecting overengineering, here are some example hints for detecting over-the-top efforts:

• Adding features that have never been discussed with stakeholders just because it ‘might be needed’ in the future.
• Having tons of configuration options that are likely never going to change because you want to be ‘flexible’ or avoid new releases.
• Choosing complex, scalable architecture patterns for applications that are very limited in scope and user count.
• Applying very generic programming concepts to prepare for potential future changes (usually to avoid repeating code or refactorings in the future).
• Insisting on 100 % test coverage for a prototype or proof-of-concept project.

What is your view on overengineering? Have you experienced some of these examples, or would you add other tell-tale signs?

Note: You can also find this episode on YouTube and Spotify.

#SoftwareEngineering #Complexity #ITResources #Requirements