I have a question, to explain that, what better than an entirely fictional example?

Let's say you are a young developer just being employed in a firm.

All data is stored in a huge database (let's say 500+ tables with billion rows).

Your boss ask you to make some consolidation queries stuff.

So, you start making your query and, during the development process you learn a lot of conditions to add to your query.

Result? Your query works pretty well, result asked is correct but is slow and not very easy to understand.

Why? Cause the query, due to a lot of modifications became very complicated.

After that, with checking that with a colleague who work in the firms since years, he wrote the same query than you but... easier to learn and faster to execute.

So, in fact the main question is: how can we limit this useless complexity ? How can make code more logic in fact?

Actually, my initial idea was to draw activity diagrams of code to see where are bottlenecks but I think a better approach is possible.

Looking for Books, Links, Ideas, Approaches, Methodologies...

  • @gnat: I don't think this is a duplicate - one can create perfectly readable, but nevertheless unneccessary complex code (though the solution for both cases may be the same).
    – Doc Brown
    Mar 27, 2013 at 12:12
  • @DocBrown I firmly believe it's dupe: "parent" question clearly states "easily maintainable" requirement, which to me wipes out a way for "unnecessary complex" to leak through
    – gnat
    Mar 27, 2013 at 12:14
  • @gnat: I tend to agree that the questions overlap to a certain degree, but in this question the focus is more on "semantics", while IMHO the other question has a stronger focus on "syntax".
    – Doc Brown
    Mar 27, 2013 at 12:18
  • 1
    Not an exact dup, but some good related answers here. Mar 27, 2013 at 12:35
  • 1
    "Fictional" examples still have a basis in a real situation you've encountered, otherwise you wouldn't be asking the question.
    – alroc
    Mar 27, 2013 at 13:31

3 Answers 3


Well, in your example, you already provided the only solution that really works: ask someone else for reviewing your code.

To limit useless complexity at first hand, you need experience you get over years by learning, learning, learning. There is no "silver bullet".

  • I'm agree with you, experience comes with strong years of labor :-) But, honestly, I'm not searching a cookbook about how writing better code but maybe some approachs who can help me handle a better way of working. Does methodologies like SCRUM take care of this kind of problem ?
    – eka808
    Mar 27, 2013 at 9:36
  • @eka808 The methodological component that works best is getting someone else to review your code. Any methodology that includes that is likely to help keep complexity down. Mar 27, 2013 at 10:24
  • @eka808: what you are asking for is how to increase your problem solving competence. Well, I don't what works for you, but for me studying mathematics several years at the university worked well. Also, working several years as a programmer helped a little bit, too ;-)
    – Doc Brown
    Mar 27, 2013 at 10:41
  • +1 for No Silver Bullet. Mar 27, 2013 at 11:20

A couple of principles to help along the way:

  • YAGNI - You Ain't Gonna Need It: don't build things that you don't need. Which brings us to:
  • KISS - Keep It Simple, Stupid: the simplest solutions are often the best.
  • DRY - Don't Repeat Yourself: duplicated code often deals to a variety of issues. Like you would normalise a DB, you should normalise your code.
  • Separation of Concerns / Modularity / SRP. Keep things focussed, simple. This makes them reusable and understandable. This goes doubly for functions / methods, which become exponentially more difficult to (comprehensively) debug as they get longer (see: cyclomatic complexity).
  • Principle of Least Astonishment - people shouldn't be surprised by your code. It should do what it claims to do (e.g. if your getters are setting things or have major side effects, you're probably doing something wrong; an exception may be lazy-loading).

Remember that code is meant to be read by people, not just the compiler. Make sure your code explains itself by having clear names for everything. If something is surprising, leave comments to explain the intent / why it works like that, not what it does. A good book to read on this topic might be Clean Code.

I'm also a big fan of refining solutions iteratively. I guess you can call it refactoring, except it's often without the TDD element, and sometimes involves major changes rather than tiny ones.

I think the value of the above practices and principles really comes together when they are all applied; things become short, simple, obvious.


Here's some ways:

  1. Choose correct level of complexity. The required functionality determines minimum level of complexity, and the solution should be using that level. Too complex and you need to handle too much of it, Too simple and you can't meet the requirement.
  2. You can't predict the future. Some people think they need to choose more complex version simply to make it possible to meet some arbitrary future requirements. This is bad idea. Arbitrary means that anything is possible. The only thing your complex solution can do is make it more complicated. It cannot solve any problems, since you don't have enough details about the problem.
  3. Details are the king. Complex requirements demand that all the details are correct. It's not complex if the smallest details are not important. Follow the requirement structure accurately and it'll work.

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