What is Overengineering?

Overengineering – More does not have to be better

Overengineering describes a situation in which a product is designed to be more robust or has more features than necessary for its intended use or as expected by the user. As a result, the effort and costs in development, maintenance and servicing increase. The development time and possibly also the probability of product failure increases. In addition, solutions often become more complicated to operate and the performance of the solution suffers.

This phenomenon also exists in services and even in processes the term overengineering is often used; whenever a process is unnecessarily complex or inefficient. In such cases, the term overkill is also often used.

Reasons for overengineering

There are several reasons for overengineering:

• The striving for perfectionism, because only when a product also supports features X and Y is it a perfect solution in the perception of designers and developers.
• Ignorance of the actual wishes and needs of the customers, due to a lack of communication with stakeholders and incomplete processes for requirements collection.
• The orientation towards existing solutions on the market and the associated feeling of having to deliver similar basic and performance features.
• Requirements can change and new technologies appear which question earlier design decisions. In this knowledge, system and software architects like to design solutions that provide expansion options or interfaces that are not yet needed.

The right balance between over- and underengineering

In product development practice, it is difficult to find the right balance between overengineering and underengineering. What is the dividing line between good design and too much design? How can you find out in a code review which parts are actually needed and which have already been implemented for future, imaginary requirements? When developing products, it is certainly advisable,

• not to make solutions more generic than they have to be,
• only provide expansion options if it is very likely that they will be needed in the future,
• and to obtain feedback from customers and users at an early stage.

Impulse to discuss:

Is overengineering a logical consequence when development teams want to avoid creating technical debt?

Notes:

If you like the article or would like to discuss it, please feel free to share it in your network. And if you have any comments, please do not hesitate to send us a message.