One of the Mikes sez, Hell is Other People’s Code.
It’s interesting watching the process of how truly horrible crap gets written…
The worst piece of code I ever saw took me by surprise and was a little poignant, because it was written by a person who I had had some respect for.
Let’s make a distinction between messy code and bad code. Messy code is the stuff you find whose formatting is random, whose style is inconsistent, and that probably uses variable names like ‘jj’ and ‘argh’ and ‘tryThis2’. You know what you’re looking at is poop. But bad code can masquerade as perfectly good code until you start digging, whereupon you fall through the clean surface and into a pit of rotten garbage and sewage where creatures with big sharp teeth and bad attitudes are not remarkably thrilled about having you drop in and tweak them around and try to fix bugs. Of course, a lot of bad code is messy, and a lot of messy code is bad, but it’s not a requirement in either direction. The critters are . . . hungry.
Anway. This person (who we’ll call SC) wrote some stuff that I liked, and I thought he had a good head on his shoulders. But when we got the latest drop of the OS from the company he worked at, all of our applications were suddenly taking at least ten seconds to start up, where before the startup time had been nearly instantaneous. Those of us lucky enough to have systems with four megabytes of RAM (yes, that was a lot in those days) had to wait well over half a minute: for each shell operation, for each invocation of ‘ls’, for each compile, each link. Fourty seconds each.
The culprit turned out to be the piece of code that zeroed an application’s unused memory when it started up. While before this had been a call to memset (which was in assembly language), it had been turned into nice, portable C, into something like:
*addr = 0;
MoveMemory(addr, addr + 2, severalMegabytes);
In other words, an overlapping memory copy that (as a hack) propagated the initial stuffed value. This was on a 68000: No cache, barely any prefetching, slow as a grandmother in pre-game traffic.
I replaced it with the code that had been there before, got our dogfood customers off my back, and (lo!) we could use our computers again. Then I gave SC a call.
“That new memory clearing code you put in the app initialization code…”
“Takes half a minute on our machines. The old stuff, a few hundred milliseconds.”
“You don’t understand what it’s doing. You see, the first argument overlaps the second, so the zero gets propagated up –”
“No, I know what the code is doing. It’s way too slow.”
“No, you don’t understand. You see that zero gets copied by the overlapping addresses, and…”
He blabbed on and on and we had an argument about how clever the new code was versus how painfully slow it had become. SC won his side of the argument, and we did, too, because they never changed that code, but we never took another drop of the OS from them, and later they went out of business in that classic, painfully slow way that marginal companies die in Silly Valley (the last step always seems to be a rented corner of a tilt-up that is shared with a motorcycle welding shop and a weird-ass industrial bakery, for some reason).
So, SC, if you’re out there and reading this, don’t feel bad. I’ve had my own circumstances where I’ve superglued my blinders on and stuck with a piece of code just because I was proud of how clever it was, and it was the wrong thing to do for the customer. I’ve definitely Been There. But this was my first inkling that it could happen to anyone, and that peers are important, and that the first real qualification for being a software engineer, after being enthusiastic and smart, is a near bottomless capacity for humility in the face of tireless machines (and users) who will prove you wrong, time after time.