The Way Roger Wrote Code

RogerBates used a drafting program at XeroxParc where he was a hardware engineer. One day he sought out its author to ask for an enhancement. He got the program instead.

I guess that's how Roger learned to write software. He cloned the program for the MagnoliaWorkstation. It was the best program ever written from scratch for that machine. It had ...

So, I used his program to do DraftingOnMagnolia?. And, one day I asked Roger if I could get the source to add a feature. Well, Roger was agreeable, so long as I promised not to complain about how he wrote code.

I've thought about listing here what Roger did wrong (in spite of my promise.) Instead I'll just list what he did right. He ...

I suspect there's a lot I missed. It's my loss.

So, why are hardware types so much better at writing code that works? And why do software guys give them so much grief for it?

-- WardCunningham

The mean-coder hardware types I've worked with have a couple of things in common: they aim first to solve the problem (other considerations, like readability and supportability are secondary), and they almost always work on software alone.

I think we (on the software side) often give them flack out of jealousy. We work under different constraints, and are judged by an entirely different set of standards. Or perhaps there's a bit of fear, as we ask ourselves painful questions about the constraints and standards we live within or have imposed on ourselves, and whether they're effective in ways that count.

My hardware friend Steve has written some slick code. I've been envious, but then I remember all of the red "patch" wires on the back of some of his boards. Is there a word in hardware for "goto?" Isn't a patch wire more like a check in to a revision control system than a goto?

-- DaveSmith (7/27/96)

Isn't a patch wire more like a check in to a revision control system than a goto?

Only if the next one you buy doesn't have the wire. Or maybe not even then, a lot of PCB layouts do have version info on them. And configuration management was originally a hardware technique.

Is there a word in hardware for "goto?"

kludge?

Notice that we use "patch", as in "-board" for odd bits of program we, err, forgot to put in the first time...

I believe the reason for the above is simply that electronic engineers are used to meticulous design up front based upon a standard set of design patterns (amplifiers, filters, etc) that conform to standard interfaces (transmission line impedances, 74LS series components etc). It is too easy for the software engineer to guess at a design and test it - doing this in electronics usually results in interesting fireworks. So it is not too surprising that a good electronics engineer will also write good code. --ChanningWalton (not a good ElectronicsEngineer? but certainly had his fair share of fireworks)

True, but when it comes down to it there are no standard design procedures for some kinds of electronics and you have to just get a feel for it. This was always my failing. Also, there is a tendency in electronics to get a good set of requirements before the design starts because people intuitively understand the difficulties that will results if requirements for hardware are changed midway. Interfaces are also well designed. Software, being much more, errr... soft and somewhat less visible as a whole to whoever it is producing the requirements, seems to be easier to change, which it is but not when the culture is one of 'make sure I don't get blamed for anything'. I doubt that you'd find a hardware designer being told by one of the 'users' that they could fix something by 'just moving this bit over there and making that chip pink'... --LanceWalton

JointApplicationDesign? they call it Lance. Wonderful stuff isn't it?

This Roger was good. Unfortunately, he was not as common as it appears - I have seen many EEs who write truly bad code, even EvilCode. And do not mistake this rant for CodeJealousy? - I have quite a few Mathematics-type friends who write code, and they do a great job, and I know of others w/o degrees who are also good - but I have a HotButton? about EEs who write ToyPrograms? and think that software is easy. -- Pete Hardie

I've worked with guys whose grasp of hardware stuff was much better than mine (sigh) and found that, for many of them, assembler (and in some cases, C) was easy for them (cuz it modeled the CPU). Their code wasn't always pretty, but it tended to be exact, often being the SimplestThingThatCouldPossiblyWork. In most cases (most, ok?) they were happy with (and good at) languages that allowed them to model the functions of components, but were less happy (and less good at) languages used to model business practices. The fuzzier things got, the less they wanted to have any part of it. Put down the rock. I said most, ok?

For one thing, I imagine that having a predictable set of data conditions makes it more possible to write "exact" code, while business data tends to have exception cases that expand in a greater-than-linear relation to the number of elements involved.

Hardware/driver type code is closer to being engineering, while business coding is closer to being art. Scientific coding is a form of engineering: science tells you why a slide rule works and dictates its general form; building one that works is an engineering job. -- GarryHamilton

I have and can write both kinds of code. When coding in an environement with a well defined stable requirements spec. When the spec a has a finite number of test cases, or large swags of test cases have simple mathematical properties"double Add(double,double);" then I can hack you up maginficently badly enigneered piece of code that fits all the *** points above and more besides. However if you then start messing with the spec and violating the tight set of assumptions I made about what you may change your mind about sooner or later my code implodes, I have nervous break down and someone else has to do the rewriting because I am sick to death of the problem. I believe the same is true of all the Rogers in the world. Where their personal limit in dealing with large balls of mud lies varies, but a big enough ball of mud will bury anyone.

If I write a magnificently well enigneered piece of code, this decay process takes much much longer. I think that if management had perhaps an extra 20% than they have ever (in my experience) been willing to spend then well engineered code would not grow crufty with age at all. Given real life experience that might sound a bold claim but, consider the axe that has been in my family for 3 generations, it has had 3 new heads and 6 new handles!!! It is still however as good as new.

Silly question: where was it said that Roger's code was a large ball of mud?

EditText of this page (last edited December 16, 2003) or FindPage with title or text search