Good vs. bad code

Browsing through some of my old posts, I found one from three months ago about why many programmers don’t seem to care about what their code looks like on the inside, as long as it works on the outside.

I thought about whether this is similar to a journalist that doesn’t care about language, but I realized that language is too vital for journalists to succeed. The fact is that programmers get away with writing sloppy code, because code is invisible. But not for long.

Generally, you can’t tell if a working program looks bad on the inside. However, if you would examine a number of consecutive releases of the same program, it would be easier. Chances are the code is poorly written if the addition of new features is slow, and if those features doesn’t blend well with the previous ones.

But with some apps, you just know that they are well written. Those apps speak their quality loudly. They are coherent, they have integrity, their UIs make perfect sense, they behave as you expect, and so on.

Why is this a good sign of the code being clean? Because software can’t be planned. Software is always a dialogue with its users, with competing software, and with its programmers. Good software adapts, and for adaptations to take place gracefully, the code must be susceptible to changes. Bad code isn’t.