Smart versus Complex Code

Dumb Code vs Smart Code

When is smart code too smart? When is dumb code too dumb. It is often said that the smartest people express the most complex ideas in the simplest ways. But in the field of software, sometimes code has necessary complexity. I must admit I have been the target of accusation regarding complex code. But how complex was/is it really...?

The Definition of Complexity

This blog is somewhat introspective, so I will ask myself: what do people mean by "complex". Secondly, is complexity really up for debate? And lastly, who decides, or perhaps rather how should we decide when something is complex and when it is necessary. Clearly, one person's complexity is another's banana (easily ingested); so...am I coding bananas or rats-nests?

Definitions of complexity may be one of the following:

1. The average human (or coder) finds it hard to understand.
2. The code looks like Frankenstein in a beat-up jalopy driving through New York City at rush-hour, while the police force, public transportation and garbage collectors are out on strike. Aka "the rats-nest".
3. The programmer has used every trick, tool, idiom, and pattern supported in the language. Sometimes called complexity for complexity's sake. Also, "job security".
4. Terseness of expression; requires an exorbitant amount of time to analyze code as correct.

Analyzing Complexity

I suppose the first question to ask oneself when accusations of complexity come flying is: "Precisely how do you perceive my code to be complex?". I suppose this dialog could be interactive with said accuser. And, of course, this question could be asked introspectively. (Much like I am doing right now...which feels a lot like talking to myself. "Wait who said that?...the inner sage...no you're not...yes I am...ummm, nevermind"). In any event, it would be good to understand the way in which one's code is complex. 

Is the Complexity up for Debate?!

After analysis, the question should be asked: "How reliable and competent is the accuser in making these accusations". This probably should be left up to one's inner monologue (perhaps that goes without saying...). In any event, their competence/experience and reliability may directly affect how we should respond to the accusation. Lets take a closer look, definition by definition:

• Average employee accuser accuses, unable to clarify how or why they think it is complex.
• If the average is pretty average, e.g. they have trouble tying their shoes. The accusation can probably be safely and sagely ignored. Move on with your life (and... stop blogging and refactoring at 1/4 to midnight)
• If you work at Sandia National Laboratory or MIT Lincoln Labs perhaps some consideration should be given to the complexity of the problem being addressed. Probably warrants investigation.
• Accuser calls out "Rats-Nest": 
• Pretty much all non-comatose humans can spot a rats-nest - it's part of our genetic make-up since it keeps our toes from being nibbled upon at inopportune times. This accusation requires some serious consideration. Rats-nests are usually fraught with bugs, conversely as code fraught with bugs is usually a rats-nest. Time to go-a refactoring.
• Except in the very unusual case that the accuser is your sworn enemy and is just out to undermine your credibility. Then, just maybe, accusation can be ignored.
• Accuser seems to have noticed that you have used the Visitor pattern in conjunction with anonymous instance classes delegating through a Chain-of-responsibility, Composite acyclic N-ary tree to draw your screens output:
• Hmmm... if the accuser was smart enough to decompose your drawing routine with that amount of detail, they might know what they are talking about. Unless that complexity is providing some serious optimization or unless the alternatives are even worse, it's time to go-a refactoring.
• OTOH, if that accuser just found out how to tie their shoes that morning and they were able to figure out the above. Congratulations, you are probably a genius and your code is most likely GOLD. Go have a beer...
• Accuser just read Design Patterns and sees that your class uses Singleton, Proxy, Null-Object, Immutable and Strategy all at the same time! 
• Newbie, alert! While their enthusiasm is infectious and noteworthy, their lack of experience is demonstrated in the fact that those patterns and idioms are as common as inheritance and composition are fundamentals of object-oriented languages. Move on...
• Accuser accuses you of using the ternary expression (GASP) and thus your code is too terse! 
• The ternary operator exists for a reason. Move along to that kick-butt recursive descent parser that you are working on...
• Accuser accuses you of placing an entire sorting algorithm packed in one line of code. 
• That's just ridiculous. Have fun at the next Obfuscated Code Conference. For everyones' sake go-a refactoring.
• Newbie accuser does not see a single if/else or switch statement in any of your code... yet it handles all sorts of special cases! 
• Ignore the newbie, and my congratulations for understanding and applying State Pattern. Reward yourself with some much needed sleep...
• Accuser sees that you have refactored 10K lines of code down to 1K lines.
• Tough call. Consideration to the quality of the original code must be analyzed. Terseness to this degree may make the overall design opaque and resistant to change. May want to refactor.
• Additionally, programmer may want to double check that hidden features such as exception safety and error recovery are as robust as the original. Perhaps time to go-a refactoring. 
• Or... Great job. The new code may be just what the doctor ordered; that is, if it is just large enough to do exactly what is needed and no less. Go have a cigar...

Living with the Guilt

To wrap up this discussion (perhaps only with myself). Complexity clearly comes in a variety of flavors. Probably the two most egregious examples of complexity are #2 "the true rats-nest" and #3 "unnecessary complexity".

• The top honors goes to the rats-nest; the reason is fairly obvious. Other forms of complexity may only make the lives of maintainers of the code difficult. Rats-nests, on the other hand, hurt everyone: coders, users, babies, small furry pets, everyone loses. Say 10000 Hail Mary's (I will pray for you)...
• Unnecessary Complexity. Most of the time unnecessary complexity is incidental. You might just have not thought of the easiest solution yet. Other times, you may just be a "fancy boy". The guilty parties know who they are... 

So when should you feel a modicum guilty? That answer is easy.

• One, when it really isn't complex at all; it is misunderstood by a junior programmer. Guilt newbie into buying a couple of books...
• Two, when the algorithm mandates it. For instance, "egrep" I have recently learned uses finite-automata to do back-tracing in O(1) (constant) time. I don't really have any idea of what finite-automata are, probably something in one of those Comp-Sci classes that I never took - but I feel smarter just saying it... finite-automata, yeah that's right. In any event, egrep can be orders of magnitude faster than grep in certain search scenarios because of... finite-automata... and O(1) back-tracing, so, clearly in this case the complexity of... finite-automata... is practical. Enjoy a SnackWells Devil's Food Cake....

• Last, terseness of expression is sometimes celebrated and sometimes scorned. Terseness and quality sometimes go hand-in-hand, but so can terseness and obfuscation. So it is probably right to feel a little guilty anyway...