The Wary Engineer’s Notebook – Part 1

One day, while in the midst of a long and really scary project involving 60 hour work weeks, an inept manager, mounds of paperwork and a customer with a meeting fetish, I had an epiphany. I put aside my work for a little while, barred my office door and attempted to capture some tiny bits of this cosmic illumination before it slipped away. A collection of little essays is the result, which I’ve edited and expanded a bit here and there using the perfect 20/20 vision of hindsight (a great thing, hindsight, too bad it’s uni-directional).

I’m not sure what to call these ramblings. They are by turns slightly cynical and slightly sarcastic, but the main intent was to look at the common activities of engineering with a, well, slightly jaundiced eye. For lack of anything better I’ll call them “The Wary Engineer’s Notebook”.

Most of all, if you’ve ever experienced things like this yourself perhaps you can get a chuckle out of it. If the world is still shiney and new to you, well, I hope it stays that way for you, but my experience has been that the dust and mud will tend to cake up no matter what. Perhaps these little essays will help you to spot where the dirt tends to accumulate the fastest.

Just remember that this is all intended to be humorous in a satirical, tongue-in-cheek way, so please don’t get spun up thinking I’m trying to insult you or your dress code. I wouldn’t dream of it. Honest.

But enough about that. I’ll proceed to post them in sections. Appropriately numbered, of course.

 

The Wary Engineer’s Notebook – Part 1

In this first part we look at engineering, requirements and testing. But we won’t look too long or too hard. As Friedrich Nietzsche put it: “…if you gaze for long into an abyss, the abyss gazes also into you.”

Engineering

One way to describe engineering is as a process of creating something from nothing[1]. Or, to put it another way, creating something that is hopefully better than nothing. The sad reality is that the something is very often no better than the nothing because management won’t leave it alone and new requirements keep popping up out of the woodwork. In those rare instances when engineering can proceed without impediments the end result can appear almost magical in its final form, thereby confirming management’s fears that engineering involves some forbidden form of the black arts.[2]

Requirements

Requirements are intended to define, at various levels of detail, the necessary functionality, interfaces and usability of a system, device or software product. As a general rule, requirements come in various levels of descriptive detail, ranging from very high-level marketing or functional requirements to very low level implementation requirements.

In reality what are often passed off as requirements are really “desirements”. In the world of software they may even have little stick figures (with labels like “actor” or “user”) and use words like “should” and “attempt”. It is highly unlikely that anyone in sales or management could tell you the primary characteristics of a well written requirement even if their life depended on it. So don’t bother pestering them about it, their eyes will just glaze over, but they will still want to give you their “requirement” anyway.

In the software world there have been attempts made to do away with the musty old flow-down paradigm and its up-front requirements. The idea is that the requirements can be built from the bottom up based on vague and inconsistent end user input. This is not only a fallacy, in some cases it could be considered to border on active sabatoge of software engineering in general. Unfortunately, as with object-oriented programming, some manager or corporate VP will be gullible and ignorant enough to think that this is a great idea, and you will get stuck with trying to make it work out. Good luck with that.

With hardware the amount of wiggle-room afforded by logic gates and op amps isn’t quite so broad as with software, so the requirements tend to be a bit more well-defined. That doesn’t mean, however, that someone is going to actually take the time to do an FMEA or FMECA on the hardware design and compare the results to the requirements.

If you have readable requirements to work from then consider yourself lucky. If you have well-written requirements then you probably work in aerospace. If you have no requirements and a manager who insists on just getting it done, then you might want to consider getting a different job. Or perhaps take up something less stressful, like, say, driving a garbage truck (it actually pays pretty well; I know, I checked).

Testing

Testing is another of the deep mysteries of engineering. Some people do it well, some do it haphazardly, and some just manage to botch it up no matter what. Testing badly done is worse than no testing at all[3]. At least with no testing one knows that there is a high probably that something is wrong, but with badly done testing there is a false sense of security based on inaccurate results. In the latter case the fecal matter can really hit the rotary air motion device when it is announced that the device or software is “tested and ready to ship”, only to have it fail in some particularly embarrasing way in front of the customer.

This is also one of those activities where management types seem to be unable to understand why the person who designed and built something can’t also be the one who is going to test it. It’s as if they all took nothing but open notes tests in college and can’t believe that the world doesn’t work that way as well.

 

Notes:

[1]  Theodore von Karman (one of the founders of the Jet Propulsion Laboratory) once said:
“Scientists study the world as it is; engineers create the world that never has been.”
And you thought I was just being a smartass, didn’t you?

[2]  Look up “Magic” in the jargon file. You can find a copy here:

http://www.isri.unlv.edu/~slumos/jargon/Table_Of_Contents.html

[3]  This little gem has been around in one form or another for a long time, but it never ceases to amaze me how few people have heard it or actually seem to understand what it really means.

Advertisements

0 Responses to “The Wary Engineer’s Notebook – Part 1”



  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




Follow Crankycode on WordPress.com

Little Buddy

An awesome little friend

Jordi the Sheltie passed away in 2008 at the ripe old age of 14. He was the most awesome dog I've ever known.


%d bloggers like this: