[lug] can't make this stuff up, folks...

[Nate Duehr]

On Oct 16, 2009, at 6:12 PM, Carl Wagner wrote:

> That brings up another point.  The new Kaiser Permanente add saying  
> on how they have switch to electronic records to save trees.  When  
> was the last time your paper record was hacked by someone in North  
> Korea and sold to identity thieves?  Want to bet how long it takes  
> now?

LOL!  Yeah.

> The problem with software is it is very complex.  Imagine after  
> building the first foot bridge by some guy a few thousand years ago,  
> and then within a generation having to build the Empire state  
> building and the space shuttle.

Yeah, but the engineers (I'll give them the title... they really  
ENGINEERED the Shuttle flight computers, but at a very high price $$$,  
perhaps that's the TRUE cost of using computers?)... really did a nice  
job on the Shuttle stuff, and that code has proven over time to be  
virtually bug free in all areas where it really counts.

> I am not optomistic we will ever get there.   The foundation for  
> other engineering disciplines does not change "much" over time.   
> EE's deal with inductance, impedance, latency, and then just need to  
> get the bits or signal from point a to point b with some  
> conditioning.  You can model just about any engineering discipline  
> in software,  but you can't model software in any other engineering  
> discipline.   Show me how to model a kernel using resistors,  
> capacators and transistors, or steel, concrete and wood.  Yes there  
> are FPGA's but that is really just software again.   That seems to  
> make all other engineering disciplines VERY constrained.   Is that  
> the problem?  To be a "real" engineering discipline, must the field  
> be highly constrained?  I would say that would rule out software  
> forever!/?

See, that's always been my point... most software CAN be broken down  
into component parts... all software does some macro things... takes  
input, calculates, creates output... add a GUI and this gets hard to  
visualize, but it's still happening in a tiny scale on every user  
interaction.  So if you have a pile of functions to do such things,  
and do REAL code re-use (and stop chasing the software language flavor  
of the month), your old bugs don't return... because they've already  
been squashed.  I know it's not THIS easy, but how many of you have  
watched professional coders start from scratch and NOT use libraries?   
I've seen it... too many times...

The part that REALLY freaks me out a bit is the number of buffer  
overflow errors continually found in OS's!  Really? The same mistake  
over and over?

I guess in order to be "fair" I should point out us "sysadmin  
professionals" rarely work from checklists, write down formal upgrade  
plans, etc... I have had the opportunity to work with a customer who  
REQUIRES written documentation of EVERY command typed into their  
systems as root, and it's a bit eye-opening when you realize they  
rarely have human errors on their systems.  Seriously measurable  
results.  But did I want to rebel against it when co-workers first  
described their procedures to me?  Yep.  Big time.  "I have to write  
up the commands that are going to be run to clean up old log files in  
a directory, submit them as part of a documented plan for a  
maintenance window that's only ever allowed on a specific night of the  
week after 9PM Mountain, and have it approved by the customer before  
they'll even set the root password to a temporary one that we can  
use?"  Yup.

So... it's POSSIBLE to be that disciplined... just very few companies,  
bosses, people... have ever had that culture.  In this one particular  
customer's case, the culture came from externally -- different  
technology prior to computer use (yeah, they're that old), and it  
continued into computer technology.  They highly value uptime.  But  
they actually went looking for a way to truly accomplish it, not just  
measure it and keep doing things the same old way.  (Well, actually...  
THIS way is the same old way for them...)

I didn't "believe" at first. I originally HATED working on that  
account... after a few months, the written documents started becoming  
a challenge... can I make them better?  Some common maintenance items  
re-use the documents, of course... but could I make them better?  I  
could!  Neat!  As a pilot in my free time, I started realizing what I  
was doing was creating my own "sysadmin checklists"... and just like a  
pilot, you know how to fly the plane, the checklist is checked to make  
sure it was all done correctly and nothing was missed, and can also be  
a memory jogger on a "down" brain day... even used as a "warning sign"  
that you're not a sharp/ready to accomplish the mission as you thought  
you were... notice you did something wrong because your checklist  
helped you catch yourself, you're now more aware that you're mistake- 
prone today...

Anyway... I just THINK that similar discipline can be done in coding,  
but my professional coding portion of my career only lasted about 3  
months... so I can't speak as an "insider" about anything other than  
being a sysadmin/troubleshooter... not a coder.  I just like  
challenging coders to think about it...

QUITE a surprise this week was while reading Chesley "Sully"  
Sullenberger's new book (the Captain of US Air 1479 that had to land  
the aircraft in the Hudson River, for those who don't recognize the  
name), before he became a "celebrity", he was working on creating a  
consultancy to bring some of the traditions/culture found in Aviation,  
to business.  I felt a little vindicated... another pilot thinks the  
same thing... "Business/IT would benefit from a bit of the discipline  
in Aviation"... wow.  Neat idea.  I have been thinking it for years,  
but probably don't have the skill to articulate it well enough to have  
thought of starting a consultancy and speaking on the topic.  Frankly,  
it sounds really cool.

--
Nate Duehr, nate at natetech.com