Note: This originally appeared on the Compassbill Blog in March 2010. As that blog is no longer active (and CompassBill is now Billmation), I figured this was too good to let languish over there. Some editing has been done to improve the content, and remove the marketing copy at the end of it.

From the title of this post, you might think I am referring to the famous whitewashing incident in The Adventures of Tom Sawyer. While developers have been known to creatively get out of work, I am referring to the end of The Adventures of Huckleberry Finn.

For those who aren’t familiar with the story, I am referring to Tom and Huck’s plan to break runaway slave Jim out of captivity. All things considered, a very simple and easy plan could have been executed to get Jim out. Instead, the plan becomes needlessly complicated, involves an amazing amount of additional work, and almost results in getting Tom killed.

Why did they go to so much trouble when a simpler plan would have worked? Because Tom felt the simple way wasn’t the proper way to spring a prisoner. According to his understanding of the process from reading books such as The Man in the Iron Mask and other classics, a breakout had to be complicated and harrowing. Thus instead of a one night job, it became a mess full of “pet” spiders and snakes, cobbled together shovels and knifes, and a rope ladder baked into a pie.

As a developer, I must admit that far too often I’ve fallen into the trap of “complicated = better”. Like other people, overcoming complicated situations make me feel good, even if some of those complications could have been avoided. Sometimes these complications come about because of a desire to do it right, to follow what a book or what conventional wisdom says is the right way. Often times this takes longer than a simpler, if inelegant, solution was taken, and is rarely ever better than the simple solution.

The ideal application gets from point A to point B in a straight line. That isn’t always possible right off the bat, as the simplest path isn’t always the quickest path, or the easiest to spot. This is especially true when dealing with legacy bloatware. However, a clear goal of simplicity, dogged determination, and passion for refactoring can make sure you can get to that elegant solution.

It’s as easy as pie without a rope ladder. (Sorry, I had to go there. I was powerless to resist.)