[lug] software engineering

[Nate Duehr]

Sean Reifschneider wrote:
> On Mon, Nov 13, 2006 at 04:39:08PM -0700, Evelyn Mitchell wrote:
>> An example of this that we've all encountered is using the phonetic
>> alphabet to read back a word that needs to be entered exactly as typed over
>> the phone. "aBcd" = "lower case a as in alpha, upper case b as in bob,
>> lower case charley, lower case d as in delta".
> 
> I've trained myself to notice when I'm running particularly sensitive
> commands or in production environments and behave slightly differently in
> certain contexts.  For example, if I'm doing a "rm -rf" or "rm *", I will
> almost always give the full path to the entity I'm trying to remove.  "rm
> -rf /home/jafo/Maildir-spam/*".

Yeah, me too.

> For example of why, years ago I ran a production-test system that
> suddenly lost part of it's database files.  I spent 36 hours, because of
> a snow-storm that blocked access to the necessary tapes from across town,
> recovering this system.  The end result was that a user had typed
> "cd / home/username/test" followed by "rm -rf *".  Note the space after the
> first slash after "cd"...

So you were taught by someone crashing the plane for you.  Maybe there 
is some value in a formalized apprenticeship or level process wherein 
you would have instead been taught this technique more formally and 
trained and tested on it before being cut loose with root privs?  You 
don't see many shops doing that -- yet.

> I often, when running on production systems, will stop myself where I'd
> normally hit enter on a command, and re-read it and really think about the
> consequences of running it, before hitting enter.  This sort of "slowing
> down" of the process can really prevent errors.

Very much so.  Similar to the thinking a pilot does before flying an 
especially difficult instrument-only approach to an airport in bad 
weather.  You gain a sense of when something is more likely to kill you 
and you think and behave in a more structured and consistent manner.

I won't reply to the other e-mail, but I like your correlation to 
programming too -- tips and techniques to save your bacon like the 
bracket idea.  Nice.

How do we start to move toward a formal knowledge transfer process for 
these types of behaviors in IT?  More important, how do we change the 
current motivations of both the workers and the bosses so that they WANT 
that level of formality and discipline?

Nice examples, great discussion -- filled in a lot of holes for me to 
some extent as to the "why" the less critical things simply never get 
looked at or fixed.

Nate