Among pilots there's a somber expression: "All warning labels are written in blood."
Intellectual respect vs practical respect
As a youth this concept was drilled into my head at ground school. It was sufficiently 'drilled' that I even thought I understood it. However, when my first day for actual flight came, it became apparent that while I had gained a respect for the words of this phrase, I really hadn't internalized its true import.
I can still remember that day vividly. I was giddy to just get into the plane; I positively could not wait to be up soaring through the sky -- In my mind I'd paid my dues with hours of ground school. As I look back I can plainly see that as far as I was concerned that day, the pre-flight checklist was something that was keeping me from flying; I wanted to get through it as quickly as possible so that I could get on with flying.
To my instructor, the pre-flight checklist was something completely different. It wasn't just a trite checklist that tolerated because it sounded wise. It wasn't just a recommendation. It was a tool that allowed him to keep doing what he loved best: flying. For him the checklist wasn't keeping him from flight, it made flight possible. You see, it's hard to fly if you're dead; something he understood all to well from his nearly innumerable years as a professional aviator.
define:metaphor
If you were to ask the average graduate (high school or college) to define a metaphor you'd probably get something akin to "a comparison of two unlike things without using the words like or as." While that may technically be accurate… it does very little to define what the POINT of a metaphor is. The beauty of a metaphor is that it allows us to take something we're familiar with, cast it into a new light, and through the new view we have on it gain new insights into what it was we thought we understood so well in the first place. The main strength, then, of metaphors is that they usually allow us to take something esoteric, or poorly understood, and view in the context of something we know very well. In the software industry we're actually all quite adept at using metaphors to explain what it is that we do, and how we do it. We call ourselves architects and engineers (do we REALLY build things? I'd argue that we're so tuned into the metaphor of building that we have a difficult time thinking of software in another light-- but we don't really 'build' things do we?). We spend a good deal of time chasing down bugs… why bugs? Well, etymology will tell us that the origin of that word comes from the fact that a real moth had once logged itself into some vacuum tubes, but I think it's safe to say that currently we don't actually think in terms of REAL bugs when we create software, or when our customers complain about it; rather, I think we've moved into a metaphorical realm where we're describing elusive 'critters' that everyone accepts as fact of life, despite the fact that they are an non-desired reality.
I could go on, and if I did I'd of course have to ramble on about how metaphors are powerful because no single metaphor accurately describes anything. In other words you can use multiple metaphors to describe any single aspect of life and gain benefit from it. I'd also, of course, have to mention that metaphors aren't always accurate, though as humans we posses an innate ability to spot metaphorical heresy.
Wrapping it up … almost
Now, before you begin to think that my intention here is to compare FLYING with software development, let me set you straight: that's not my intention at all. Well, it's not my intention, but as a quick stop off in the power of metaphors… I can't resist a few observations. The reason I can't resist quickly commenting on them is the fact that I think they provide a good insight into what is WRONG, in many ways, with software development/information technology today. For example, when's the last time you heard a CEO say something like :
The corporate jet is serving the company well, but ground crew costs are out of control. The secretarial staff has been on planes A LOT, they're also EXCELLENT at setting up itineraries, therefore it's only logical that we get them to start taking care of maintenance…
Nothing this asinine could happen in the 'real' world, yet we can all see similar occurrences in development/IT. Another great 'truism' that can arrive from the comparison of flight to development comes from the fact that while plenty of people in the world have no clue EXACTLY what makes a plane fly (just as they have no clue what makes computers/software work), they also don't feel safe dictating that certain, fundamental, aspects of aerodynamics change to meet their needs (especially if they're planning on 'riding' in the end-result). In other words I don't think any pointy-haired boss in the world would last long at Boeing if he said:
Seriously guys, this thing has to be able to fly from Paris to Hong Kong in 2 hours, and has to be built by this Friday… attaching the wings is taking too much time... time that we simply don't have. You've got the propulsion system and the cock-pit in place, let's just roll with it -- we can fix the defects later.
Wrapping it up … for real
Okay, now that we've had a bit of fun with a reckless metaphor, let's jump back to the purpose of this post. You see, in the years since my first day of flight I've had a good amount of time to ponder on the significance of what I learned that day. Two things stick with me most:
1) Rules/Warnings/Protocols exist for a reason (most of the time) and to ignore them is usually signals a conscious choice to incur some potential, future, consequence,
2) My instructor's experience gave him a completely different outlook on safety protocols than my let's-just-get-in-the-plane-and-fly mind-set provided me.
Sadly, there really isn't a good word in English to describe the lack of true respect for wisdom that differentiated my mind set from that of my instructor (something tells me that German has a verb for this…). In other words, how, in English, can you sum up the difference between logically acknowledging a wise purpose and completely trusting in something to the point where it doesn't become just a good idea, but becomes an entire way of life? What word describes that?
Why should all of this matter? Simple, if I could find a word or a concept that accurately described this 'breach' of acknowledgement/trust I'd then have the target of my metaphor. You see, in software we all know that there are right ways to do things and less-than-right-ways to do things. I like to think of this as the difference between theory and reality. Somewhere between both polar opposites is a happy medium where we can find success. My hunch is that we're not there; we may be close, but we probably stray from the mark more often than we come close to it (the good news is that we then stumble off to a new project glad for what we learned, and happy that somebody else has to deal with our mess from now on).
Sure, pointy-haired bosses can be blamed for a lot of what keeps theory from blending with reality to form a new flavor-of-the-month, but bosses can't be blamed for reality. Indeed they shouldn't be blamed. Saying that 'reality' gets in the way of theory is a cop-out. Theory is supposed to address reality. For my instructor safety precautions weren't theory, there were a protocol that couldn't be ignored, no matter how much people might be in a hurry. He had had too much experience, and had gained too much respect for the horrible consequences to treat safety as anything other than a primordial priority. (And yeah, I also see that one overwhelming problems in our industry is that those around us don't have a healthy enough respect for the 'horrible consequences' of what can happen in 'dev gone wrong.') BUT, and this is a huge BUT: my instructor also was not a nazi. He wasn't some puritanical freak with a clip-board and a pen, and he didn't enjoy flying because he loved running through a checklist. He didn't go out to the hanger to walk around his plane, kick the tires, test the rudder, look at the engine, check the lights, and then go home. No, he was there to fly. The safety check is what kept flying repeatable for him. It also kept it enjoyable. You see, nothing in flying sucks like crashing… and with that we're back to establishing a harmony, somehow, between theory and reality. The harmony that my instructor had between safety and fun.
It's this harmony that I want to focus on as I blog on sqladvice. Indeed, one of my chief desires is to delve more into this exact topic, the struggle between theory and reality. In the future I want to touch on aspects of this 'controversy' that we take for granted; aspects that bug us to death, aspects we think we can change, and aspects we SHOULD change.
Stay tuned... it should be a good ride (though hopefully not a 2 hour trip from Paris to Hong Kong)...