A year or two ago I saw an excellent article on OOP (Java), which showed the progression of a simple concrete logger of two or three lines of code, and a theoretical excessive thought processes by the inexperienced developer that basically said oh, I should add this in case we ever want that! By the end of the article this simple logger was a giant mess of garbage that the original developer could hardly understand himself...

Is there a common term for this type of over-complication? That article (which I dearly wish I could find again) shows the concept wonderfully for an isolated case, but I've come across entire projects where the developers had essentially programmed themselves into a knot by over-use of patterns, frameworks, libraries and other issues. In its own way, this is as bad (or even worse) than legacy VB6 spaghetti apps we inherit for replacement.

What I'm really looking for is to bring this up when interviewing. I want to know if someone is aware and conscious of how easy it is to fall into this with lack of architecture/pre-planning (and getting a fell for whether they seem to have the correct balance in place), but it's not really something I can find a lot of info on.

  • 25
    Yeah, it's called OOP. – gardenhead Mar 4 '17 at 17:19

The most frequent term I heard to describe such designs is overengineering. The original meaning of that word, however, is not related to software development, and outside of software development it has probably not such a bad tone.

On a more general level, Joel Spolsky gave designers who overcomplicate architectural designs the name "architecture astronauts".

However, especially for an interview, I think it is more important to know what the opposite is called, putting only things into a design which are actually needed and forget about the unhealthy "just in case" approach - this is called the YAGNI principle.

  • Thanks. I'm big advocate of YAGNI, wasn't sure if there was a common opposite. – jleach Mar 4 '17 at 13:46
  • I would stress that yagni is about "what is actually needed right now". You should still leave things out, even if it is known it will be needed later, as long it is not needed right now. – Bent Mar 4 '17 at 14:16
  • 7
    @Bent I would stress also that it does not mean to completely ignore things/changes you know for sure are going to happen in the near feature... knowing how the software will be extended after can guide you to write code that will be more easily refactorable along those axis of change. – Bakuriu Mar 4 '17 at 22:09
  • I've been using the term "poor-engineering" as opposed to "over-engineering". I've worked with people who love to add all kinds of features and "just in case" extensions that don't have clear use cases. If you fail to understand the problem you're trying to solve it's just poor engineering. – Josh Johnson Apr 18 '17 at 21:42

Yes, overengineering is the simplest term to describe this. I have seen overengineered, unnecessarily-complicated designs more times than I can remember over the years. Many years ago when taking a Microsoft GWBasic course, the instructor repeatedly hammered the KISS method (Keep it Simple Stupid). This is as true today as it was then.

So I always remember KISS and always design with SOLID Principles in mind. But with that being said, it's still possible to overengineer a design with SOLID principles fully considered. You have to balance a common sense, pragmatic approach with the desire to be pure and adhere to the generally-acceptable OOP guidelines. If given enough time and if you love creating intricate solutions, you can end up down the path of designing an engine for a skateboard because you thought it would eventually be turned into a car. Fortunately, I have been disciplined enough to not do this over the years, but I have seen it many times.

So to summarize, to prevent overcomplication of code:

1) KISS (Keep it Simple Stupid)

2) Follow SOLID principles with practicality in mind.

3) Don't try to design for every eventuality. And sometimes small, leaky abstractions are not horrible things, if they are isolated, intentional, and if the effort to prevent them far outweighs the effects of keeping them.

4) Consider the implementation of solutions while designing them. You can't just say, "oh, that's an implementation detail", and assume your design is practical. I used to work with an architect that did this frequently, and alas, his designs never worked, and as a result, I don't work there anymore.

5) Code as if you are the one that is going to maintain it.


So, you are going to have this interview and you intend to trick the candidate into displaying what he knows about software engineering and then you are going to say "Nah, you probably want to apply all you know in your first assignment, move along now, you gold-plating over-engineering non-business-value creator! Shoo!"

I think it would be safer to present a concrete example and discus the pro's and cons of applying certain patterns. Than you would be soliciting for responses like "It depends, do you want it fast? Will this be all? How complicated is the problem? What patterns are already in place?" and you may learn something yourself. This would also allow the candidate to prove his sense of context while it would be a more open question. Waiting for and wanting a specific answer will at best get you someone with the same biggest concern as yours. If you do not get your answer it could be the candidate just regards it a no-brainer.

  • 4
    I'm sorry, but I was really just wondering if there was a term for it. I wasn't looking for advice on how to conduct an interview (or to have my question be perceived in any way as to how I would conduct an interview). Thanks for your concern though... – jleach Mar 4 '17 at 16:46
  • 1
    Well, you did write that last paragraph in your question which is hard to ignore and quite a statement. If you do not appreciate feedback on certain parts of your text you may want to be more restrictive in what you put down. – Martin Maat Mar 4 '17 at 17:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.