Is there a term for over-complication of OOP?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.