Does anyone else have the feeling that solutions for simple projects are often overengineered?

Question

Somehow I've got the feeling that many projects become heavily overengineered so every possible change-request can be tackled with the effect that the change-requests that occured are very hard to implement.

Somehow I get that feeling in nearly every project I'm currently working on. It is like everyone is thinking "which cool api, framework, etc. can we add to the project to tackle this and that aspect" without evaluating if it is practical or needed.

Does anyone else feel the same or what's the opinion of the community here?

Answer 1

Yes.

-- MarkusQ

Answer 2

I find that, while some older companies with 'senior' senior management tend to be extremely rigid with how their business code is created, newer companies completely lack a backbone of what software they use to get the job done.

The problem you describe sounds like people are viewing problems at too high a level and want to find a way to solve it in one go. Creating a working toolbox (think standard libraries) would help them out in the long run.

I particularly enjoy the UNIX way of things: Several tiny utilities that do one thing and do it really well.

Answer 3

Definitely - I think people get 'robust and modular' and 'overengineered' mixed up far too often.

Answer 4

I'm yet to work on any real world problem but I've read enough people blogging about this to assume there is a problem.

Answer 5

Guilty as charged. Three levels of abstraction and six config files is just more fun to implement than a simple flow control branch.

Answer 6

Overengineering is a danger in any project, large or small. When writing for code extensibility, there's always a trade-off between writing code that is sufficiently generic and extensible to allow for future development and code that is specific enough to make the task at hand easy.

Every "future hook" has a cost and should be evaluated in the light of that cost, the probability that it will ever be used, and the cost of refactoring later in the game. "More generic" is not always better.

As for using a hot, new framework or API, I think project managers should take a gentle hand in this. With development being such a fast-moving field, hands-on self-training is part of the price of doing business (but obviously should be kept reasonable.)

Answer 7

I've only encountered that with Java people: "Lets use spring!" And hibernate! I found this cool validation package as well! And this one will create XSLT to create XML forms to create the javascript!"

By the time I find all the jars and get them to play nice, there are dozens of classes I have to be familiar with. And then they want to abstract away all those pieces! "We might switch spring out. Or not use hibernate, so we should abstract those away". Add another dozen hacky wrapper classes.

By the time its all done, 50 lines of psuedo code has turned into several thousand lines of making the "cool stuff" work, and about 100 lines of business logic trapped within its hairy, hacky, bug-ridden hell.

I'm guilty of it myself, too, but thats only because I'm bored and have time to kill.

Answer 8

I think Dave Winer captured the cyclical nature of this phenomenon well:

The trick in each cycle is to fight complexity, so the growth can keep going. But you can't keep it out, engineers like complexity, not just because it provides them job security, also because they really just like it. But once the stack gets too arcane, the next generation throws their hands up and says "We're not going to deal with that mess."

Answer 9

The key thing to keep in mind here is time. A "simple" project that is knocked out of the park on day one by an Excel spreadsheet or a web page can quickly expand in both its audience and scope to become an unsustainable monster.

Under-engineering is a danger, too. The world is full of "practical" people who will mock any efforts that are contrary to their opinion. Nobody remembers the person who disagreed a year later when the "simple" solution can't be sustained.

The trick is to balance the right degree of engineering and be able to adjust when things change.

Answer 10

I've been bitten a few too many times by applications that I've thrown together quickly which have subsequently become "critical" apps. Then I have to almost rewrite the darned thing. I just assume now that it will become critical and so I "write it right" the first time. Saves me time and effort in the long term. So oddly, it's about laziness.

Answer 11

Absolutely. But it's not just developers, it's users too. "I want this and that and the other in order to improve communication and increase productivity!".

I'm amazed at how many of these types of projects we've solved by just putting a shared folder on a file server.

Answer 12

I think this is a problem, but not as big as it seems and that there are good reasons for it.

The problem is that most projects that are underengineered will die a quick death while the overengineered ones can survive. Thus, when you look at still living project, there is survivorship bias.

And, even if you are a good architect that aims for "just good enough", if in doubt you will use the more flexibe, scalable, ... (i.e., overengineered) solution. Because the failure mode if you do not meet the requirements (whatever they may be) is usually much worse than what happens if you exceed them.

Answer 13

As others have said, I've had too many 'small' projects become big ones and the short cuts taken become paint.

There is a place for a quick-and-dirty solution and in trying to follow the YAGNI mantra, I've created simple apps with no engineering.

With that though, you are not going to be able to jump into a million line system and develop the 'well engineered' system without practice on smaller systems.

I've taken to always following the developed architecture of our company in all projects because it helps me to work out solutions in line with the engineering principles we are trying to follow.

What you practice, you perform, so always do your best.

Answer 14

Yes. I think people nowadays think more about how something should be done, and whether "it's the right way ..." and so on, than just picking the simple solution which will equally get the job done. If you're not asked to expand it, then don't think about expanding it.