Digital Minefield

Why The Machines Are Winning

Programming’s Three Tasks

Recently, an old programming friend in Florida sent me a link to an online book about JavaScript. I don’t do much with Java, but it did get me thinking about all those books on how to program.

There are scores of such books (particularly now that we use so many languages), but there are also a great many books on how to program User Interfaces. That is, how to make the user’s interaction with the program transparent (some say intuitive).

Unfortunately, there’s a disconnect in the code created by these two approaches. The concerns of good style don’t overlap those of good user interfaces. Should users even care about style?

Non-programmers don’t realize that even the simplest program can be written a million different ways. Of these, a hundred are probably flawless. Of the hundred, a dozen could be perfect in every aspect of their construction and execution. There is no best.

However, perfect code can still be opaque to the user. Clearly, the answer is to write clean code, then make it easy to use. Finally, improve the style without changing its functionality.

Regrettably, the programmer’s job is still not done. The concerns of style and user ignore the future of “finished” software. This is maintenance—and its usually eighty percent of the total effort.

When the first completed version (1.0) is released to the world, the responsibilities of maintenance begin. Whether it’s quick fixes, like typos, or major revisions and upgrades, the job usually goes to programmers who did not develop the program.

So, even after writing code that is kind to users and has excellent style, there are still the needs of the maintenance programmers. To meet these, software developers must write readable code.

In a recent search, I found exactly three books on writing readable code. Still, that’s three more than existed when I wrote a paper on this topic some twenty-five years ago.

Without readable code, maintenance is more than difficult, it’s nigh impossible. But readability cannot be another step, nor an afterthought. Doing it as you write aligns code with concepts.

Six months after a program is complete, you may be the one who has to fix it. After that long, you may be a stranger to your own code. If you made it readable, you will appreciate the effort.


Single Post Navigation

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: