Wandering Thoughts archives

The two sorts of (programmer) certification

When you're talking about certifying people, there are really two sorts of certification; certification of people, and certification of people and procedures. In yesterday's entry I was implicitly talking about the latter sort of certification, so today I'm going to explain why.

First, one of the usual stated goals of programmer certification is to move to an environment where software is more reliable and secure, like the work that engineers produce.

At the best, certification of people is a stamp of approval that you've learned the necessary knowledge for your field, that you know how to write programs properly. But only part of the problem is due to ignorance, and even with everyone perfectly educated the economic pressures against reliable and secure software will still be there; such software will still cost more to build without making companies any more money. Merely educating people on how to build reliable and secure software doesn't do anything to make sure that they will actually build software that way.

(At the worst, certification of people is nothing more than a tax or a guild.)

Certification of people and procedures together means that not only do you know what to do, you have some sort of legal liability if you don't follow the approved procedures for doing things. It is not enough to know how to design bridges or write programs properly; you must design your bridges or write your programs according to certain standards, or you are liable if they fall down. (The certification of people is more or less to attest that they're competent to follow the proper procedures, so that their work doesn't have to be checked all the time.)

If you want to genuinely change people's behavior, to really get them to create reliable and secure software, you must give them no choice about it. This means you need people plus procedures certification with its accompanying legal liability for people who do not conform.

(As a practical matter you need some sort of liability shield; making people personally liable for bad programs no matter what they did would be a great way to encourage programmers to take up another career.)

Why software engineering certification may not work out the way people want

Proponents of requiring programmers to be certified generally have in mind the model of engineering and an outcome much like how certification has worked out for engineers; often this is made explicit with labels like 'software engineering certification'. In this model, the programming world keeps evolving at almost its usual pace, much like engineers keep building new sorts of buildings with new designs, but it does so in a (more) disciplined way so that programs don't fall down so often.

But there's another model for how professional certification can work out, one that I think is more likely to happen: the medical profession, where ordinary doctors do not innovate and instead follow approved procedures generated infrequently by comparatively few people.

The crucial difference between the two models is that engineers can demonstrate beforehand (and afterwards) that their new design was safe according to general understanding and principles. To do this, engineers rely on building from materials with known properties so that they can confidently analyze the effects of various stresses on their design to insure that it is safe.

(If the design blows up anyways because of some new, previously unrecognized source of stress, I believe that the engineer is legally off the hook.)

There is no such thing for doctors. For doctors, it is 'this probably should work; I guess it's time for the animal trials'. As a result, ordinary doctors by and large cannot innovate because they have nothing to build on and no way to analyze their plans for safety; innovation comes from the few that have the opportunity to do direct safety tests for new developments. It is as if engineers could not use a new bridge design until an example bridge had been constructed and then had the maximum safe load driven over it.

In other words, engineers not only know how to build a safe bridge, they know how to prove that it is a safe bridge, and the ability to prove it is crucial for their legal protection when they propose a new design. Without the ability to prove it, engineers would have to stick to known and proven designs.

In this respect, programming is a lot more like medicine than it is like engineering. We don't have the practical ability to prove anything about programs or about development practices; instead what we have is 'best practices'. Thus I expect the results of meaningful programmer certification to be much more like medicine than like engineering.

My problem with Lisp

I would like to love Lisp, I really would. But I have a small, shameful problem that gets in the way:

Trying to read Lisp code makes my eyes bleed.

This isn't because I can't stand Lisp itself; it's more because I can't seem to stand the way that the Lisp community has decided to format Lisp code.

(Through some magic process that seems entirely at odds with their fractious nature, the Lisp community seems to have standardize on a code formatting standard to the extent that there doesn't even seem to be a debate about it.)

In thinking about it, I believe that there are several things about the standard way of formatting Lisp code that contribute to my reaction:

• the Lisp community seems to be strongly against interior blank lines (or other whitespace) in functions. The effect for me is an unrelenting assault of text.

  (One result of this is that it is easy for me to lose my place in the text; when reading, I use the visual patterns created by blank lines as a kind of high-level orientation to home in on my current location.)

• clauses in things like (if ...) are not indented to the same level.
• indentation levels are small, so I have to pay close attention to really see an indent or outdent.

  The two of these combine to make it hard for me to absorb the structure of Lisp code by skimming in the way that I'm accustomed to for languages like C and Python. (And yes, I consider two-space indentation in C to be an abomination. I am not fond of the GNU C coding standard.)

• the S-expression structure of Lisp means that control structures and variable assignments do not stand out; instead everything looks the same and I have to read carefully to grasp what is going on, instead of being able to categorize lines more or less at a glance.

Another way to put it, I think, is that the sameness to me of formatted Lisp code makes it hard for me to follow it unless I pay it a huge amount of careful and slow attention.

Now I find myself wondering if well-honed Lisp people have similar issues when reading C, Python, and so on. Or perhaps recognition of certain things is basically automatic for readers in general, because we've been conditioned to notice blank space and indentation and so on in text in general by years of exposure to written words formatted in a particular, customary way.