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.

  • 29
    Yeah, it's called OOP.
    – gardenhead
    Commented Mar 4, 2017 at 17:19
  • "a theoretical excessive thought processes by the inexperienced developer that basically said oh, I should add this in case we ever want that!" They also think that all future developers will use their overly abstract and "future-proof" code. They themselves forget how to use it, how it works, or that it even exists. If there's any amount of churn in a team, it gets even worse as things become more and more forgotten. We can preach DRY all day, but at a team level it's a difficult concept to enforce and maintain. Commented Aug 19, 2022 at 16:51

3 Answers 3


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
    Commented Mar 4, 2017 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
    Commented Mar 4, 2017 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
    Commented Mar 4, 2017 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. Commented Apr 18, 2017 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). If a simple solution meets the requirements, then step away from the code, call it done.

  2. Follow SOLID principles, but 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. Martin Fowler has an excellent writeup on YAGNI (You Aren't Gonna Need It) related to this.

  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. And I don't mean that it's a license to be sloppy because you understand all the in's and out's of the code; I mean that if you are going to be doing maintenance, then you will want to make your life easier by following good principles, outlined in my 4 points above. And by doing so, you also allow other maintainers, particular junior developers, to not pull their hair out because you left a big ball of mud for them, with broken abstractions and layers of chicken wire and bubble gum holding it together.

  • I completely disagree with point 5. I try to code as if a junior developer has to work with it. They don't need to understand every facet of the code, but they should be able to jump in to make simple modifications or fix quick bugs. If I wrote my code as if I were the only one going to maintain it, I'd the luxury of knowing what I wrote and where, others don't have that luxury and shouldn't have to dig through layers and layers of abstraction to find something trivial like an off by one error in the one place in a mess of code that's got any actual business logic. Commented Aug 16, 2022 at 20:59
  • Hi Joel, thanks for the comment. You misunderstood what I meant, but I realize now that I wasn't succinct enough, so I'm updating my answer. Commented Aug 17, 2022 at 21:19
  • 2
    SOLID, especially the Open/Closed principle is the opposite of KISS/YAGNI.
    – JacquesB
    Commented Aug 18, 2022 at 5:39
  • KISS and SOLID are not entirely mutually-exclusive, and they can be implemented together, but only to a certain point. This is why I stated KISS first, and SOLID second, with the caveat of keeping practicality in mind. Whenever flexibility is needed, one should always consider simplicity first, regardless. If using KISS meets the requirement, then great, but if there's an unavoidable complexity involved in the solution necessary to meet the requirement, then proper application of SOLID principles is absolutely necessary in order to craft high-quality code. Commented Aug 18, 2022 at 11:59
  • 1
    I like that, Joel, MISS. :) Unnecessary interfaces is the first sign of superfluous code created because of the desire to remain pure. You have to be practical with all of this stuff, or else what does it really matter. Thanks for the banter, this stuff can be so theoretical which is why it's almost always done incorrectly. Commented Aug 22, 2022 at 15:09

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
    Commented Mar 4, 2017 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. Commented Mar 4, 2017 at 17:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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