AES as a test of software engineering

I've recently been using an AES CCM program that someone wrote at work a while back - apparently downloading one of the many public implementations was a bad idea, for some mysterious reason. It works. I'm using it to compare to hardware, and since the two are completely independent versions, if they agree its virtually certain that the hardware is correct. So far so spiffy.

I've only briefly looked at the internals of the program but I have read the wiki page, and its fairly clear that, whilst not exactly rocket science, getting the code right is far from trivial. And I know this in the other direction from personal experience, as I struggled with getting the encodes to match whilst guessing what byte-ordering the hardware used; as is deliberately the nature of this stuff, if you get even a tiny bit wrong the whole output is junk.

But the interesting bit, to me, is that I regarded the guy who wrote the program as close to incompetent. Certainly I wouldn't have trusted him to do anything major on his own, and I watched him struggle on a variety of tasks making simple mistakes that someone else had to come in and undo. And this throws up the difference between software engineering and programming. I'm a software engineer, at least in my own mind and in my job contract. The amount of time I spend actually writing computer code is a small fraction of my time. Its clear you can be a reasonably decent programmer - at least in terms of making programmes that produce the correct output - whilst being rather poor at the overall software engineering task (though even there I should qualify that somewhat. If you poke into the internals of the code its a mess, sufficiently so that I didn't stay in there for very long. And in terms of design, it doesn't really produce the output you want it to, exactly, nor does it allow you to input data in the form you'd want to, and the commenting is poor, and the documentation also. So much so that a simple perl script to pre-format the input and play with the output massively improved my productivity).

So much for the example. Onto the generics. Software engineering - collaborative working on a large codebase years old - is about far more than just making the bit of code you've got now, to work, just on its own terms. The code has to fit into the overall structure without bending what's already there, without breaking the poorly documented assumptions, permitting future maintenance and extension, to be readable, to run fast enough and not use too much memory; and more. And it has to do what it supposed to do, which - a familiar plaint - is frequently not quite what you've been told its supposed to do.

This makes recruiting people hard. Being able to write coherent C is a basic requirement, but its not sufficient. Unfortunately, its the only bit that really possible to hard-test in the limited time available. You can talk about all the rest, but its hard to judge bluster from real experience. In my experience.