Did you ever see a developer boasting of himself because he created a hard-to-understand code? Perhaps you ever fancied yourself doing something like this:

void Run( const std::string& v, int tgt, int start ) { for( ; tgt >= 2 * start + 1; ++start ) Run( v + ' ' + boost::lexical_cast( start ), tgt - start, start + 1 ); std::cout << v << ' ' << tgt << std::endl;} int main() { Run( std::string(), 10, 1 ); getchar();}

(Source: http://www.cplusplus.com/forum/lounge/13042/)

Complex code is bad code

spaghetti-code A good developer knows complexity is his enemy. When we work with real software we have to fight it. Complexity hides errors, makes software obscure, and is a hindrance to maintenance. If all that doesn’t bother you, think in your own wallet, mainly if you’re a consultant, a freelancer, or own a company.

Did you ever work with code written by yourself a long time ago and had a hard time? How could you write such a hideous thing? If you were more careful, perhaps it would keep you or a colleague from future nightmares, isn’t? Of course it would! And hope shines if you are now able to see that!

Complex code is bad code. Maintenance will require too much refactoring and testing. Did you ever see a messed program you prefer rewrite it thoroughly instead of just make the changes required?

“Oh, but we have comments, don’t we?”, you can argue. Not so fast! Many will oppose to you. To begin with, processes like XP (eXtreme Programming) states that the code should be clear and self-explaining. Comments often are our enemies too. They can indeed fool us stating something the code doesn’t actually does. In excess, they pollute the code visually and make our sources longer.

Be simple

One approach to escape complexity is the principle known as KISS: “Keep It Simple, Stupid!“. Let’s outline a few steps from this “rehabilitation program for bad developers”:

  • Be humble, don’t think of yourself as a genius.
  • Break down your tasks in sub tasks: don’t work more than a few hours in the same code.
  • Study seriously about cohesion, coupling, class and method responsibility, SOLID principles.
  • Solve the problem first, then code the solution.
  • Don’t be afraid of throw code away.

An experienced software engineer should know how to use the available tools to produce the desired result with the minimum complexity and effort.

On the other hand, developers love to reinvent the wheel. In my first years as a developer, I thought to my myself: “I have no reason to learn framework XYZ if I can write my own framework!”. Yes, I’m guilty. I wrote a lot of small frameworks. Did it help me? Of course! I tested my own limits, learned the internals of these little monsters and then realized the importance of the work of other developers. I threw much code away and now I’m happy using frameworks and tools knowing exactly how they work and why they do what they do.

Simplicity example

Watch this video as if the guy at right was you in college and the guy at left you with years of experience.

Conclusion

Who cares if the program takes a bit less time to run or how much “pretty” the code is? Are we talking about the developer’s ego?

A mature IT professional should strive to improve his communication abilities. Whatever is your specialization, all artifacts in the development process should fulfill its purpose in communicating the information as effectively as possible.

Furthermore, it’s better keep our artistic skills for things like the International Obfuscated C Code Contest:

#define _ -F<00||--F-OO--;
int F=00,OO=00;main(){F_OO();printf("%1.3f\n",4.*-F/OO/OO);}F_OO()
{
            _-_-_-_
       _-_-_-_-_-_-_-_-_
    _-_-_-_-_-_-_-_-_-_-_-_
  _-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 _-_-_-_-_-_-_-_-_-_-_-_-_-_-_
  _-_-_-_-_-_-_-_-_-_-_-_-_-_
    _-_-_-_-_-_-_-_-_-_-_-_
        _-_-_-_-_-_-_-_
            _-_-_-_
}