Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What is "over-engineering" as applied to software? [closed]

I wonder what would be a good definition of term "over-engineering" as applied to software development. The expression seems to be used a lot during software design discussions often in conjunction with "excessive future-proofing" and it would be nice to nail down a more precise definition.

like image 929
Vlad Gudim Avatar asked Jun 16 '09 12:06

Vlad Gudim


People also ask

What is over-engineering in software engineering?

Overengineering (or over-engineering, or over-kill) is the act of designing a product or providing a solution to a problem in an overly complicated manner, where a simpler solution can be demonstrated to exist with the same efficiency and effectiveness as that of the original design.

What is the issue of over-engineering?

What is Over-Engineering? Over-engineering is like overthinking — you're trying to find solutions to problems that either don't exist yet or are too early to tackle. In the end, you've designed and implemented your system with too much logic, too many abstractions, and an excess number of flows.

How can we stop over-engineering?

Four ways to avoid overengineeringMake requirements transparent. Be sure to communicate dependencies and collaborate as necessary to come up with the best solutions. Evaluate your product early and often with simulations of how it will be used so that you can identify if your product is delivering the expected value.

Is Computer Engineering close to software engineering?

The major difference is that software engineering involves more of the design elements, implementation, testing, and maintenance of your software. Computer engineering deals more with the physical or hardware systems.


2 Answers

Contrary to most answers, I do not believe that "presently unneeded functionality" is over-engineering; or it is the least problematic form.

Like you said, the worst kind of over-engineering is usually committed in the name of future-proofing and extensibility - and achieves the exact opposite:

  • Empty layers of abstraction that are at best unnecessary and at worst restrict you to a narrow, inefficient use of the underlying API.
  • Code littered with designated "extension points" such as protected methods or components acquired via abstract factories - which all turn out to be not quite what you actually need when you do have to extend the functionality.
  • Making everything configurable to "avoid hard-coding", with the effect that there's more (complex, failure-prone) application logic in configuration files than in source code.
  • Over-genericizing: instead of implementing the (technically uninteresting) functional spec, the developer builds a (technically interesting) "business rule engine" that "executes" the specs themselves as supplied by business users. The net result is an interpreter for a proprietary (scripting or domain-specific) language that is usually horribly designed, has no tool support and is so hard to use that no business user could ever work with it.

The truth is that the design that is most easily adapted to new and changing requirements (and is thus the most future-proof and extensible) is the design that is as simple as possible.

like image 101
Michael Borgwardt Avatar answered Oct 04 '22 00:10

Michael Borgwardt


Contrary to popular belief, over-engineering is really a phenomena that appears when engineers get "hubris" and think they understand the user.

I made a simple diagram to illustrate this:

Somewhat sarcastic illustration of over-engineering

like image 29
0scar Avatar answered Oct 03 '22 23:10

0scar