Just over two years since I last wrote in this blog. For long months I suffered terribly at the hands of the Erinyes. They scourged me with sharpened punctuation marks, raging over the Ardor’s death from neglect. My neglect. I slumped and shambled my way back through a long walk of shame, withering in the silence of Calliope’s apathy. It will not be easy to make amends. I’d best get started.
A colleague of mine is leaving the job soon. His departure is definitely our loss, and it started me thinking about a common characteristic in some of the best folks I’ve worked with over the years. Hopefully I’ll have figured out how to put it into words by the end of this post.
A decade ago, a friend of mine was working on simulations of flight dynamics for an aerospace project. They were using an off the shelf simulation product. He was mostly just adding some custom objects and scripting for their particular application. (Apparently the cow object in the standard library was pretty close, so he copied and customized those. Little did his boss know that their system was essentially a customized cow in orbit.) Problem was, the simulation routinely crashed part way through. Technical support from the vendor knew of the problem, but their developers didn’t have a root cause, a fix, or a workaround. So my friend started digging through mountains of log files and API documentation. He broke out a debugger and stepped through the program. Less than a month later, he wrote up a description of the cause of the bug and sent it to the vendor, complete with a recommendation for a fix, all without ever seeing their source code. The simulation work became the centerpiece of a milestone demonstration to a large customer.
Modesty aside, I’ve done this kind of thing myself, particularly in researching the behavior of complex systems. Need to know exactly what happens if radar data comes in at the same time the communications gear is getting power cycled while the user’s console is transitioning from maintenance mode to operations? I’ll find out. If I don’t know off the top of my head, I’ll check the requirements specifications. If it’s not there, the designs. If it’s not there, I’ll read the code or hardware schematics. If I don’t have them, I’ll get them from the crimson-robed priesthood of the document repository, whose profane whisperings drive men to madness. If they’re not there, I’ll call and email the developer. If she’s out, I’ll bug the rest of her office. If they can’t help me, I might just ask for travel approval to go to their site and search for myself. When I find the answer, I’ll tell you in plain English, back it up with quotations from the relevant documents, citations of where the info came from, and while I’m at it, I’ll probably find out when the last time the relevant requirements were verified so you know if you should have confidence in the behavior of the current build. Come to think of it, better check all those information sources and note any discrepancies or gaps in traceability as well.
This colleague of mine, though… I think he’s not actually made from human parts. Parents recall their offsprings’ infancies in soft and doting terms. I do not doubt his parents get misty-eyed describing how he was alloyed and annealed. He makes his judgment based on the engineering data before him, and naught else can move him. He takes attempts to beg, bribe, cajole, bully, and intimidate him as further confirmation of the gruesome truths in the raw data.
I once watched him predict a system failure resulting from poor engineering practice. His dissent was holding up approval, and his opposition brought in a room full of twenty engineers to refute him in front of his boss, his boss’ boss, his boss’ boss’ boss, and the executive leaders of two other departments. Two hours they argued with him, but not once did they offer substantive data. The more they pushed, the more he dug in his heels. He acquiesced to proceeding only once he was certain he’d done his job — the executives responsible for making the decision fully understood the risk they were taking. Two days later the incident happened just as he’d predicted it. Next time they listened.
There’s a thread in all this. Be relentless. Easier to say than to do sometimes, I know. But then, if it were easy, no one would stand out because of it.
Will you be writing again soon, oh great engineer?
Re-reading this post, it must’ve been late at night indeed when I wrote it. Oh well.
In any case, I’ve got a stack of topics I should be writing up as posts, and an even bigger stack of topics that would make great posts that I can’t write about. Hopefully soon, though. I’m told blogs are best updated more often than once every few years.