In case NASA is listening

Diverging once again from the world of programming...

NASA has just announced the new Space Launch System.  No surprises here - they're taking the Shuttle components and reshuffling them.  Similar proposals for Shuttle component variants were made back in the 1970s before the Shuttle ever flew.

There's nothing technically wrong with this new "big rocket" proposal - The problem is improper allocation of public resources: Spending $3 Billion a year on NASA is a great idea... but we don't need NASA to spend that money on building big rockets any more. Commercial companies like United Launch Alliance, SpaceX and Orbital Sciences can do that quite nicely.

NASA's building a new big rocket, using Shuttle hardware, in part to keep subsidizing the companies that supplied the Shuttle components... and that's just not fair to the commercial launch companies.  If Rocketdyne wants to commercialize the Shuttle Main Engines on their own launcher, that's great.  If ATK wants to try to commercially sell their Solid Rockets to launch people into orbit, that's terrific.

The point is, there's no new knowledge to be gained by NASA building another big rocket to get things to orbit.  We already know how to do it with "off the shelf" technology.

"Big rockets" are so 20th Century anyway...  There's little need for hauling "big" payloads in the first place - We've perfected orbital rendezvous and know how to dock spacecraft to assemble "big things" in orbit.  If it's too big to fit on a Falcon Heavy or an Atlas V, then send it up in sections.

NASA should focus on what we do after we get to orbit.

NASA's spending should focus on Ion Thrusters and other propulsion technologies instead of on big rockets.  Why take a 9 month journey to Mars on a "big rocket" when an Ion thruster craft could get you there in 39 days? (NASA plans to spend $3 Billion a year on their new "big rocket", but only $400 million a year on Game Changing technologies such as this)

NASA's spending should also focus on making things in space (or on the moon) instead of on hauling things up from the Earth.  We'll never be more than visitors to space until we can build and repair things there. A Lunar base without a good machine shop won't last for long.

NASA's goals shouldn't be mundane "go to the Moon" or "go to an Asteroid" or "go to Mars".  NASA's goals should be to enable us to actually live on the Moon, an Asteroid, or Mars.  Anything less simply isn't worth doing.

Update: 29 Sep 2011:
Elon Musk of SpaceX announced his company's plans to create a reusable launch system... Somewhat along the lines of the DC X which languished and died back in the 90s.  Big programs sucked up all the money, living very little for researching new approaches... Which is probably what the new SSL will do if it goes forward.

Update: 23 Oct 2011:
NASA rejects a study that concludes that NASA could forgo the heavy-lift and use existing smaller rockets, combined with fuel depots, to reach its targets more quickly and less expensively. 

Visible Business

The key to writing really good software is to truly understand why you are writing that software in the first place.

Occasionally I'll create software for my personal use, but most of the time I'm writing software for someone else.  I write the software because "It's my job"... or more precisely because "It's my job to write software to satisfy the requirements that 'my boss' gives me".  Perfectly true, but not in the least bit helpful.  There's a rambling chain of events that leads from "an idea" to "requirements", and prior to that there are innumerable events and coincidences that lead up to "an idea" that's worth doing.

You often have to delve way, way back in time to truly understand why you are writing that specific piece of software.

I am going to suggest that if the software you are writing is Business Software, then at the innermost core of your requirements you are very likely to find something related to Business Visibility.  The raison d'être for your software will be tied to someone's need to know what's going on in their business.

At the heart of most Business Software are Business Events.  Something has happened.

You may be writing software to detect or determine that "Something has happened", or you may be writing software to deal with the fact that "Something has happened".

Either way, visibility is the key... your software is either making "something that has happened" visible, or your software is making "something that needs to happen" visible.  Your software may be making "something" visible to people, or your software may be making "something" visible to another system.  This is obviously a gross simplification... but it's often a useful one.

With Business Visibility as our goal, we can now begin to make sense of things:

Business Activity Monitoring - Some kind soul has been thoughtful enough to instrument their software.  When "something happens", they make note of that fact.  Often times they'll update a database table somewhere, or they may "broadcast a message".  Business Activity Monitoring is all about seeing those changes.

Business Rules - You've got all sorts of data - and you need to figure out what to do with it.  Perhaps "something just happened", but what you do about it depends on many other things.  Business Rules connect the dots to help you see what needs to be done.

Business Process Management - "Something happened", and you figured out that "what to do about it" requires performing multiple steps.  Business Process Management provides visibility into all the things that need to be done, when they need to be done, to whoever needs to do those things.

Business Analytics - A whole lot of "somethings" happened, and a whole lot of other things were done in reaction to those "somethings".  Business Analytics is all about helping folks see (from numerous perspectives) what happened in the past, and using those insights to "see" into what's likely in the future.

As programmers, we're likely to be asked to write software that deals with any of these aspects, or any mix of these aspects, of Business Visibility.  We'll likely get mired in the technology aspects of the problem very early on, and we'll likely spend most of our efforts overcoming the technical hurdles of the problem - but if we lose site of the fact that Business Visibility is the real goal we'll probably screw up.

Conceptually, the Visible Business is very simple to explain and to understand.  Our Business colleagues know what they need to see, and all of the minutiae attached to those needs (security, timeliness, etc.).  Let's do them a favor and not complicate that conceptual simplicity with our own arcane software concerns.

Why Johnny can't find a good job

This post is a bit of a departure from my usual commentary... but I think it's good for programmers to occasionally think about the world beyond their boundaries.  Today I'd like for you to think about why it's so hard for people to find "good jobs"...

I was born in the late 1950's, and from the following chart (courtesy of wikipedia) you'll see that the population of the world has roughly doubled in my life time...

That in itself should start you thinking...  If there are twice as many people in the world today then there were when I was born, then we'd need twice as many "good jobs" for people to work as we did back in 1960.

You might think that the relationship between "workers needed" and "total population" would be a relatively constant percentage... and for most of human history it probably was... but that ratio is dropping as can be seen in the following model proposed by Colin Clark (also from wikipedia)...

It's a bit of a stretch, but let me assert that most "good jobs" fit into the category "Primary and Secondary Activities" in Clark's model.  "Good Jobs" are generally those where you actually get to produce something.  "Good Jobs" are those where your efforts result in a tangible contribution that benefits the lives of others.

Here in the USA: "manufacturing as a share of the economy has been plummeting. In 1965, manufacturing accounted for 53 percent of the economy. By 1988 it only accounted for 39 percent, and in 2004, it accounted for just 9 percent."

USA Manufacturing Jobs percentage over time

Many of those manufacturing jobs went elsewhere - but many simply disappeared as manufacturing technology improved.

Unfortunately, many of our efforts as Programmers and Engineers result (as a side effect) in the elimination of what were once considered by many to be "good jobs".  We build machines and software to reduce the amount of human effort that is required to accomplish tasks.  For example, when I was born, working in an Automotive Assembly Plant was considered to be a really good job... but now it's pretty clear that Industrial Robots have taken over most of what used to be "skilled labor" in that industry:

The end result (where we are today) is pretty easy to understand:

Increased Population + Increased Automation = Fewer "Good Jobs" Per Capita

And that's why Johnny can't find a good job.

The Never Changing Nature of Work

Sandy Kemsley has posted a really short-but-sweet presentation on the spectrum of Business Processes and the way we need to manage them entitled The Changing Nature Of Work.  I think Sandy is spot-on with her analysis... But call me a malcontent... she's mis-titled her deck.   I just don't believe that the Nature Of Work ever really changes.

Some processes are 'Predictably Repetitive To The Point Of Being Boring', and other processes are 'Then A Miracle Happens' by nature.  Most processes are a mix of these two extremes... and they always have been.

What's changed in recent memory is our ability to effortlessly interact with people "who aren't here" in real time. We haven't changed, so the number of people that we can effectively interact with hasn't changed... but now that group of people can be scattered across continents and hemispheres without adversely impacting the efficiency of our processes (in theory).

One of my favorite clients once told me:

"The only difference between theory and reality is that in theory there is no difference."

That's where we have to focus some of our "Social BPM" efforts... on reconciling the theory that geographic dispersion doesn't matter when the reality is that geographic dispersion really does matter.

Chatting "in real time" when it's noon in your time zone but 2 am where your colleague lives isn't going to solve many of your process problems.... and trying to coordinate simultaneous "face time" when your team is spread across the world is a major and often unreachable goal.  Suddenly those people you've added to your process are a drain, not an asset.

We've got the Technology to "Flatten the Earth", but those darn Time Zones are still there... so our BPM tools really won't be Social until they make it easier to deal with that inconvenient truth.