What Is Code?
This is the question asked by the title of the main (38,000 words!) article in the June 11 of Bloomburg’s BusinessWeek. The question is answered thoroughly (38,000 words!) and with patience for the lay reader. But is it the right question?
While it’s useful to know what is code, it’s more important to address the whys of code. Why is code so expensive? Why is code so obtuse? Why is code getting worse? And why is code not the answer?
The question, why is code so expensive? could be better framed as why is the new code so expensive? The answer is because it has so little in common with the old code. The article talks of a newly hired CTO, who inevitably will hire programmers proficient in the new language.
The next question is, why is code so obtuse? It’s as though programmers are a cult believing in the mysticism of the cryptic. Look at the examples in the article and you’ll see a trend over the years towards more concise code. If it’s a game, it was done fifty years ago by Ken Iverson with APL—and done better.
As mentioned in last week’s post, Pride is a bad character trait for programmers. Their goal is to say: I can write that code in one line. (Remember the Quiz Show, “Name That Tune”?)
The preference for cryptic code is a serious problem. For decades it has been estimated that eighty percent (80%) of programming costs is for maintenance. Some other programmer has to modify the code. Unless the laconic language is supplemented by extensive comments, it’s a mind-numbing job (often solved by rewriting whole sections of code).
The question, why is code getting worse? has been partially answered by the responses to the previous two questions. However, there are many more reasons, far too many to enumerate all of them.
The push to newer, more obtuse languages is just one reason. The biggest contributor to worsening code is the increasing inability of programmers (and their managers and project leaders) to see their job as serving users first and foremost.
Clever programmers rarely see beyond their own egos. They would rather their code dazzles the user than be transparent and do the job with a minimum of fuss and muss.
The question, why is code not the answer? is not simply all of the above. It lies within the much larger picture of the history of programming (of which code and languages are just a part).
Many useful methods have been invented over the decades but fewer and fewer of them are being applied. For example, new software never replaced the old without first extensively testing in the real world.
I can’t say this is never done, but more and more I see instances of software changes put into use without any testing. I’ve even seen bank software being changed as I was using it. There are no excuses for such foolishness in a professional environment.