Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

It seems alot of times on stackoverflow, that people (programmers especially) tend to over complicate a solution to a problem to where the solution is vastly much more complicated then the original problem? Im not an expert by any means, but alot of times I try to go with the simplest solution that works (and obviously this doesn't work EVERYWHERE) but i've had pretty good success with suggesting simple solutions on the job that people seem to overlook for MUCH more complicated solutions?

Is this like a normal thing for programmers.....or am I just not thinking in the correct perpective.

share|improve this question

closed as not constructive by gnat, Thomas Owens Jan 15 '13 at 18:27

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

1. Yes, I think sometimes. 2. Yes, at least some programmers at least some of the time over-complicate their code, at least some of the times intentionally. 3. Cases closed. – Job Apr 1 '11 at 18:25
Have you ever had someone yell at you, "You should have thought of that!" when you missed some requirement that wasn't stated in the initial requirements gathering? That is what can lead to some making things more complex than necessary. – JB King Jan 15 '13 at 18:35

15 Answers 15

up vote 14 down vote accepted

Obviously, some programmers are eager to show how smart they are by making some outrageously complicated code that no one can understand. Other programmers are firing at such a high level, that complication in solutions is a natural evolution.

Some of the worst code I've ever seen was a method that had over 2000 lines of code in it. No doubt this code was complex, but it was also very poor.

I think that a good programmer avoids overly complicated code. This includes avoiding the temptation to force a design pattern to fit into a solution that doesn't really require it. It also includes avoiding God-objects, magic buttons, premature optimization, premature generalization, and other anti-patterns.

I am constantly refactoring and looking for opportunities to simplify my solutions because complexity growth is an organic thing. Like many other organic things, it must be trimmed and pruned if we want it to continue to be usable. I hate having to interact with overly complicated solutions because with increased complexity comes increased likelihood of breaking the code.

I think that readability is the most important element of code maintenance, and overly complicated solutions almost always decrease readability, and increase maintenance costs.

share|improve this answer

I've seen plenty of code that was more complex than it needed to be and nearly always for these three reasons:

1) Over-engineered because of premature generalization or trying to anticipate future needs that never arose

2) Developer(s) wanted to learn/experiment with a new design pattern or technology they'd not used before and shoehorned it in even when it was overkill. They do it because it makes their job more interesting and they get to learn something new.

3) Features and bug-fixes were added, but the existing code was not correctly refactored at the time along with it. It might only be a small piece of duplication or tacking another flag argument onto a method but it all adds up. Effectively, hacks are added and it doesn't take long for everything to get over-complicated due to all the code smells. This is the most common and usually just due to not knowing better or time pressure.

share|improve this answer
+1: Especially for #3. – Jim G. Apr 1 '11 at 19:40
I'm guilty of #2, I fear. With experience (and maturity ?) I now tend to refrain myself though... and experiment at home instead :) – Matthieu M. Apr 3 '11 at 17:43

It's absolutely a common thing. As most books say, a good developer knows how to keep it simple. It's just too easy to over complicate something with a new technology or a "cool" framework you just found, so you begin looking for ways to use it, instead of thinking from the problems perspective.

As Martin Fowler said, those who learn a new technology have a short term issue where its "technology" driven solutions.

share|improve this answer
-1: As most books say, a good developer knows how to keep it simple. - You're absolutely right about this. But then you implied that abuse of new technology is the biggest cause of overcomplicating the code. You're wrong about that. Believe me, there's plenty of overcomplicated code out there that has nothing to do with an abuse of new technology. – Jim G. Apr 1 '11 at 19:34
Where exactly did I imply that its the "biggest cause of overcomplicating code"? It's certainly an issue, "Hey, I just learned the pattern X, where I can go apply that" - Patternitus. You really put words in to my mouth there Jim. – Martin Blore Apr 1 '11 at 19:38
"I have made this letter longer than usual, only because I have not had time to make it shorter." -- Blaise Pascal Very applicable here as well. "Complicated" is often a sign of rushed, lazy, or incompetent coding. – Bill Apr 1 '11 at 20:47

I don't think it's normal for all programmers, but I have definitely seen many a programmer do this.

I think that some people believe that some people see making something really simple 'too easy', and that it's not a good showcase of their skills. Therefore, they have to make a big, complex solution that is there way of saying 'look what I can do!', even though it may not be the best solution for the problem at hand.

share|improve this answer
Thats how I look at it. IE if it's too easy it's not worth using? – user6791 Apr 1 '11 at 18:28
@Mercfh I don't understand the view. What does the ease of a solution have to do with its effectiveness? – GSto Apr 1 '11 at 18:35
I was commenting on his comment saying "Yes I agree" that prolly sometimes programmers think "Oh if it's too simple, it's not very good". – user6791 Apr 1 '11 at 18:40

I have seen programmers often write several lines of code to accomplish a task they didn't know was already built into the language. This isn't exactly intentional but can certainly be prevented.

share|improve this answer
I've seen programmers who wrote a loop for every string copy. Never used a call to a standard library function. (Whats worse is the platforms copy was optimized to read a word at a time.) – BillThor Apr 1 '11 at 20:03

It depends on what you call "simple". Some people see highly refactored code as more "complex" because there's more code, and multiple call graphs. However, this code is more "simple" in that its much easier to make changes.

I often find that a large function looks "simple" until you need to make changes, then it gets complex fast.

In other words, simple is in the eye of the beholder in many cases.

share|improve this answer
+1: too many programmers doesn't think about it – Luca Apr 1 '11 at 21:50

The problem is if you either cannot see the simple solutions clearly (this is where discussions with colleagues come in play) or if you over-generalize too early.

In other words, you make simple loops into advanced library functions because you think you will need it for your next project anyway (except that you won't in this exact form). Do this for too long and you have an immensely complex application with a very simple core.

You might also find that you need to have very robust code, and all the robustness makes it complex by default. I don't think though that this is your problem, though.

share|improve this answer

In some cases it might just be the complexity of coming up with a clean/simple solution.

There is quote which I cannot remember or find that goes something alone the lines of "Code is not complete once you have written all you need to write but complete only once you have nothing left to remove"

The lack of clarity will hinder people ability to remove all the excess.

share|improve this answer
Another relevant quote is, "I would have written a shorter letter but didn't have time." – user16764 Apr 1 '11 at 18:47
“Il semble que la perfection soit atteinte non quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retrancher.” (“It seems, perfection is attained not when there’s nothing more to add but when there’s nothing more to remove.”) – French pilot, poet and engineer Antoine Marie Roger Vicomte de Saint-Exupéry, 1939 (from the book Terre des Hommes (Wind, Sand and Stars)). – Jörg W Mittag Apr 1 '11 at 19:55
Thanks, it appears I never knew the true origin :-) Nice. – Stephen Bailey Apr 1 '11 at 19:58

The best engineers are the ones that can take really complicated problems and turn them into easy to implement and easy to understand solutions. It sounds simple, but there aren't many engineers/developers like that who exist. In fact there aren't many people like that who exist. In reality the majority of the people out there do exactly the opposite. They take simple problems and complicate them beyond recognition. Just look at our politicians for an example of people who manage to take simple problems and turn them into total chaos. Programmers are no different in this regard.

share|improve this answer
Ouch! I was just about to give you a +1, but then I saw your analogy to politics, and that's weak at best. // It's true - There's a lot of obfuscation, wasted motion, hand waving, and special interests embedded in politics, and as a result, bills may become overcomplicated. But the overcomplication is a byproduct of the obfuscation, wasted motion, hand waving, and special interests. Not a root cause. – Jim G. Apr 1 '11 at 19:38
Whatever the reason, there are very simple solutions to many of the country's problems but the politicians choose to make them harder than they need. We assume this is either because of money, power or votes but I also believe it is largely about capabilities. In which case my analogy is on solid footing. – Dunk Apr 1 '11 at 21:22

Personally, I have never intentionally tried to make a piece of software more complicated. However, I have finished something and thought "wow, that's too complicated" and went back to it and refactored. Some people may see this and just think it works and it's good enough and not refactor it.

share|improve this answer

A wise man is alleged to have said you should keep things as simple as possible, but no simpler. The same might apply to code. Sometimes you have to use a technique that some regard as complex (recursion might be a good example, it often scares junior programmers).

However, in general I think complex code often arises organically. A simple problem is solved with code that is simple, then scope expands and code is modified without too much thought, and over time you get code that tries to cover the new problem but was really designed to solve a different problem. It becomes a patchwork quilt of different pieces of logic. Such code can then often appear to be way more complex than the problem requires, but it got that way because each small change seemed, at the time, to be the easiest way to make the code work.

I don't think most developers deliberatly set out to make code complex (although you do get the odd show off who will use some technique to prove their own skill), I think code just gets that way if it is not aggressivly maintained and refactored.

share|improve this answer
It's amazing how many systems start out with a really simple core which almost fits requirement but falls short in many distinct ways, and then end up adding lots of complications to deal with lots of gaps which could have been avoided with a slightly more complicated design. Consider the simple design of C's integer types and some of the bizarrely-complex rules that go with them. If for each type there had been a "should this be promotable" option, that would have nominally doubled the number of types (though not really in a way different from a qualifier like volatile, etc.) but... – supercat May 14 at 15:54 would have greatly eased promotion/balancing rules. A non-promotable unsigned short added to a promotable int would yield a non-promotable unsigned short, whether or not short is as large as int. A promotable unsigned short added to a promotable int would yield an int. Adding signed and unsigned things of the same size, or adding non-promotable things of different sizes, would be an error. Add a tiny bit of complexity up front, and weird corner cases downstream disappear. – supercat May 14 at 15:57

Maybe a problem of a classic mistake?

30. Developer gold-plating.

Developers are fascinated by new technology and are sometimes anxious to try out new features of their language or environment or to create their own implementation of a slick feature they saw in another product--whether or not it's required in their product. The effort required to design, implement, test, document, and support features that are not required lengthens the schedule.

  • Steve McConnell, Rapid Development.
share|improve this answer

Yes sometimes we over-complicate code to entertain ourselves. Mostly though the perception that code is being over-complicated comes from an ignorant or Junior participant in the project.

share|improve this answer
-1 Senior developers who categorically blame problems on junior developers probably don't understand the motivations for their own work or the work of others. If junior developers have a hard time following your code, then IT IS too complicated. – Brandon Apr 8 '13 at 20:04
I will say that if a Jr developer finds the code impossible to understand, that is a code smell and it may in fact be that the code is too complicated, however you're using far to broad a brush here. This code smell may in fact just exist because that Jr developer needs help to understand an advanced technique, not that the technique itself is to blame. – P. Roe Mar 11 at 21:31

Another reason which hasn't been raised yet is that people may overcomplicate delivered solutions to ensure that you will need their services later on to support these solutions. In other words: for job security.

share|improve this answer
Not sure why this was downvoted, I've come across extremely large projects coded by one man, who created his own framework, and was paid hourly solely working on this project. If the employer pissed him off, the entire product line would be screwed. It would have taken months for another developer to thoroughly understand the code, while it would take a few minutes for the "all-knowing" coder to update his mess of spaghetti. – SSH This Feb 19 '13 at 21:11

YES ... and I have paid the price too many times.

My whiteboard now has a statement in asterisks at the very top which reads

"If it ain't simple, it ain't right"

... and every single time I am prototyping something on the whiteboard it always catches my attention.

It really does work for me because my complex designs do become much more simpler which translates into cleaner code.

share|improve this answer