Cheap vs Good

Disclaimer: This is not about my current project. It is about all projects, everywhere.

Kernighan once said “debugging is inherently twice as difficult as writing code in the first place. Therefore, if you have written an app as cleverly as possible, then by definition, you won’t be able to debug it.” Mr. Kernighan is soooo right. I have seen this play out several times in my career.

However, this isn’t the only kind of mess that is difficult to maintain. I also think about the opposite condition.  I could continue his statement: “On the other end of the spectrum, if you have written code in a careless manner, the mess might be too immense to maintain”. If you have ever seen one of these, you just shake your head and try hard to come up with a reason not to scrap the whole thing and start over.

This is a genuine problem in our industry. People often write hasty code without enough regard to maintainability. I’m sure that I am only the millionth person to point it out. This is part of the pain of being an elitist.

Anatomy of the problem

How/why does this happen so often?
I think it is a cause & effect cyclic dependency.  Namely: Inexperienced people tend to write messy programs because they don’t know better.  Then the only people who can handle maintenance of a messy program are the experienced programmers. Therefore, the experienced people are busy maintaining or unraveling complex messes and don’t have the time to make significant progress elsewhere (ie. writing new code). As a result, the only people who are left to write new programs are the ones who lack the skills to fix them.

Yep. It is a real “vicious circle”. I can almost hear the “three blind mice” song in the background.

Oddly, the energy that helps perpetuate this cycle comes from economics. Namely: inexperienced people are usually pretty cheap and anybody can move quicker when they don’t have to be careful (to not leave a mess). So a company saves a lot of money & time on software development up-front. The new software is launched cheap and fast, but later, these companies have to fork-out the real cash in maintenance and loss-of-functionality due to instability. Or worse, they may even have the software rewritten only to find themselves with a newer bargain-basement mess.

The root of the trouble is because it is difficult to tell the difference between a mess and true craftsmanship (within a program).  It is like buying a used car: you open the hood and then what?  Can you see a leaky head gasket, a slipping transmission or any other internal problem?  No, you have to know what to look for and how to find/evaluate it.  Once again, that adds cost.

Choose: tasty poison or bitter cure?

Unfortunately, this is one of the down-sides to capitalism.  The short-term savings just seem too tempting. So folks cannot resist the allure of a poor choice.  Each of the solutions to this problem will add a little more cost to the project overall.  It will turn your project into [the 2nd lowest bidder].  Sorry, no deal. Missed it by “that much”.

About Tim Golisch

I'm a geek. I do geeky things.
This entry was posted in Lessons Learned, Maintenance, Programming and tagged , , , , . Bookmark the permalink.

Leave a comment