Predicting or Creating the Future?

In the Jan-Feb 2012 issue of THE FUTURIST is Thomas Frey's "Eight Grand Challenges for Human Advancement." He proposes several very science fictiony things. All the challenges push past beyond our knowledge of physics. That's a good thing because I don't believe we're even close to understanding how the universe works. But what if they did come to pass? They would have some very far reaching consequences.

Can Systems Engineering account for a corrupt heart?

I was reading a Washington Post editorial a few weeks back, dealing with the tragic events around the July 23rd train accident in China.  What got me was the line:

"the government was forced to admit that a design flaw was partly to blame for the accident, and not only a lightning strike"

Looking into this further I found another article which details more issues:

"workers on duty were inadequately trained and had failed to notice or fix the malfunction."

What concerns me is the idea that these design flaws and training failures could be caused by "corruption accusations against high-ranking railway officials."

Style vs Substance?

Where's the fight?

Every now and then I get an invitation in the mail to partake in a one day seminar for Edward Tufte's “Presentation Data & Information.” I've never been able to go but the invitation I receive has a wonderful reproduction of an 1869 information map by Charles Joseph Minard. On one graphic, Minard depicts multiple variables: size of the Napoleon's army, temperature, location, time in months and direction of army’s movement on a map. It really is a well thought out graphic and it inspires me to create better and more informative graphics.

Emergence: The Mystery of Systems Engineering

It’s a well know cartoon. Two scientists are gazing at an eminence blackboard filled from top to bottom with a complicated formula filled with mathematical equations and process jargon and symbols. One of the scientists points to an area of the blackboard where the process states, “Then a Miracle Occurs.” He explains to his partner, “I think we need to be more explicit here in step 29.” I can’t but laugh every time and yet it’s so profoundly true it makes me shudder.

Our whole Systems Engineering profession is build around decomposition, implementation, integration and verification. And so this mystery (or miracle) of emergence is just assumed or taken for granted. I teach this stuff at the graduate level and even I am unsure how to explain why properties and/or capabilities will emerge when you put together components of a system. Even though these various individual pieces have none of the properties and/or capabilities of the larger system. It just happens.

My interest in emergence came about when I was exploring the phenomenon of "Unintended Consequences." I wanted to know if there was a way we could plan and manage these unexpected results of our system development efforts. “Unintended Consequences” are basically unwanted emergent properties. And just like the senseless task of looking for an “unknown, unknown” risk, how can you predict the unpredictable?

You can’t, but you can at least appreciate the mystery unfolding before your very eyes.

There is an excellent book appropriately called, Emergence, by Steven Johnson which explores this topic in detail from a more societal point of view.

By the way, another really great exploration of Emergence was also done by one of my favorite radio show and podcast, “Radio Lab.” It's well worth a listen.

The Value of Failure

I have two iconic images which depict failure in a positive light. (1) A scene from the movie Meet the Robinsons: The protagonist has just had an experiment blow up in his face and as he dejectedly faced his family he is surprised to find them celebrating his failure with enthusiasm usually saved for birthdays. They explained that failure was the sure sign you're getting closer to the solution. (2) One of my favorite demotional poster: A ship is sinking, bow up and two thirds in the water. Caption reads - “MISTAKES: It could be that the purpose of your life is only to serve as a warning to others.”

Both of these cultural ditties push the one aspect of failure which makes it an important part of our lives ... it’s the “lessoned learned” which informs us of what NOT to do ... it’s the Feddback Loop into our lives, allowing us to eventually succeed.

As Systems Engineers we face failures every time we take our product in the evaluation phase of its development cycle. Will it meet the requirements, both technical and operational? And of course we’re the ones who need to evaluate the impact these failures will have on the overall project. The cost, schedule and performance issues must be addressed in a creative and resourceful way. Such is the burden and responsibility of the Systems Engineer.

Of course failures come in may sizes. Small ones from your test events that can be worked off as a “lien” against the product acceptance. Or the large failures which occur after the product has been deployed and during its operation. Lives and the environment can be ruined as a result. Just look at BP oil spill in the gulf. But no matter the size or enormity of the failure it’s still there as a “warning.” Don’t make the same mistake, learn from the lesson, embrace the failure as a part of the price to be payed towards the road of a positive outcome. It’s OK to fail, just don’t let it stop you from going forward.

The girl engineer in my life

There's a confluence of two celebrations this month that for me personally hit home.

The first: The well regarded and well know celebration of my chosen profession, National Engineer's Week. A week long celebration that makes New Orleans celebration of the Saint's Superbowl victory look like a picnic. We're talking about Future City Competitions and School presentations and other neat stuff, which I can't think of right now.

But the best part of the whole holiday is today's "Introduce A Girl To Engineering Day, February 19, 2009"

Which actually brings me to the second celebration. The less well know celebration of an obscure monk named Valentine. You may not be aware of this tradition of blessing the loved ones in your lives with cards, flowers and candy but I am one a few who know and follow the old ways.

One of my loved ones is my daughter Stephanie who is in her third year at University of Maryland, College Park, on her way to an Engineering degree. She's smart, beautiful and an absolute gem.

So I'm posting today in order to tell my favorite women engineer in my life, "I love you and couldn't be prouder. Keep up the good work."

Two out of Three ain't bad!

Here's a great article that justifies my career choices of Systems Engineer and part time College Professorship. Money magazine and PayScale.com rated the top 50 careers with great pay and growth prospects. Systems Engineer is #1 and College Professor is #3. Nice.

Even better, the Systems Engineer article mentions the CSEP as a required certification for some jobs. Maybe I'll get more students for the CSEP preparation course I teach.

Only problem is they do place SE under Information Technology. This kind of bugs me to no end. I know IT requires SE but SE is more then IT. During my recent job search I kept getting recruiters asking for a more IT related System Engineering work, i.e. Do you know UNIX or JAVA? How good are your System administration skills in Unix, Linux, and/or Windows platforms? Do you have experience with VMware ESX server, Lab Manager, Virtual Infrastructure Client? Do you have the ability to write basic scripts using shell scripting or Perl?

I got so feed up I created a standard reply:

Thank you for the info but I'm not really an IT guy or software development guy. I help PMs and their Program Offices with the technical aspects of acquiring new systems and capabilities for DoD. Milestone Documentation, Architecture review, Requirement Tracability, Validation and Verification of requirements, test planning via TEMP development, etc. Look at chapter 4.1 of the Defense Acquisition Guidebook. That will give you a good understanding of what I do. Bottom Line is my strength is in Systems Engineering/Technical Advisory (SETA) work.

I know it's kind of snippy but it was the best way for me to deal with it.

Well I got to get back to work here at the Best Job in America. OORAH!