3 ms·

> Over-Engineering is when someone decides to build more than what is really necessary based on speculation This is so wrong, in the context of software at lea

by smegel 10y ago

> Over-Engineering is when someone decides to build more than what is really necessary based on speculation This is so wrong, in the context of software at least. Over-engineered software has layers of abstraction that add nothing to the function or form of the product the costumer sees - it is over-engineering for the sake of ideological notions about design patterns etc. As for functionality delivered to the client, software very, very rarely gets over-engineered - in reality it almost always gets delivered late and with core features still in development. The idea that there is all this software being delivered on time that not only meets 100% of all the original requirements with exacting quality and perfection, but is somehow delivering in gross excess to the point of giving customers more than they need is pure fiction.

hinkley 10y ago
I don't remember who it was. Might have been Michael Feathers, might have been Jeff Atwood, could have even been Slava Pestov. One of them said words to the effect, "people over-engineer because they're so afraid of making a bad decision that they try not to make any decision at all." Make a decision. If it's wrong, own it. Develop OTHER coping mechanisms for being wrong. It's good for the ego, probably good for the soul. The fights I have gotten into with myopic people over the years have largely come down to them putting a bunch of energy into what should have been reversible decisions, and treating irreversible decisions in a cavalier manner (eg, trying to 'get it over with'). Learn to tell the difference. Be bold with the reversible ones. Put off the irreversible ones if you actually can - but know that deciding to do nothing IS often a decision. Like deciding to add security or localization 'later'.
- gaius 10y ago
  "people over-engineer because they're so afraid of making a bad decision that they try not to make any decision at all." This goes for refactoring and TDD too.
  - zem 10y ago
    how does that go for refactoring? when I refactor code I'm typically making a decision that we have now pinned down the functionality of the code, and we are going to make the structure reflect that functionality clearly and directly while stripping off incidental complexity that came from exploring the design space.
tigershark 10y ago
I remember a bloody configuration mechanism in a .net gui a several years ago where to add a simple configuration entry you had to add 3 different properties in the app.config, add three fields in three different interfaces and three different implementations, add three properties in some unrelated "adapter" class and add finally the code to access them where needed. Needless to say that it took me more time to add a bloody property than to implement a simple feature. And 99% of the time I forgot a simple step and discovered that it didn't work only at runtime. This is the essence of over-engineering in my opinion.

by smegel 10y ago

hinkley 10y ago

I don't remember who it was. Might have been Michael Feathers, might have been Jeff Atwood, could have even been Slava Pestov. One of them said words to the effect, "people over-engineer because they're so afraid of making a bad decision that they try not to make any decision at all." Make a decision. If it's wrong, own it. Develop OTHER coping mechanisms for being wrong. It's good for the ego, probably good for the soul. The fights I have gotten into with myopic people over the years have largely come down to them putting a bunch of energy into what should have been reversible decisions, and treating irreversible decisions in a cavalier manner (eg, trying to 'get it over with'). Learn to tell the difference. Be bold with the reversible ones. Put off the irreversible ones if you actually can - but know that deciding to do nothing IS often a decision. Like deciding to add security or localization 'later'.

gaius 10y ago
"people over-engineer because they're so afraid of making a bad decision that they try not to make any decision at all." This goes for refactoring and TDD too.
- zem 10y ago
  how does that go for refactoring? when I refactor code I'm typically making a decision that we have now pinned down the functionality of the code, and we are going to make the structure reflect that functionality clearly and directly while stripping off incidental complexity that came from exploring the design space.

tigershark 10y ago

I remember a bloody configuration mechanism in a .net gui a several years ago where to add a simple configuration entry you had to add 3 different properties in the app.config, add three fields in three different interfaces and three different implementations, add three properties in some unrelated "adapter" class and add finally the code to access them where needed. Needless to say that it took me more time to add a bloody property than to implement a simple feature. And 99% of the time I forgot a simple step and discovered that it didn't work only at runtime. This is the essence of over-engineering in my opinion.