Why WebOS didn't matter

I was stunned when Hewlett Packard pulled the plug on the HP Touch and its WebOS after just a couple of months...

When I first read the announcement, I couldn't believe that a major player like HP would make such a mess of things, even more so than when RIM stumbled rolling out their Playbook.  I honestly thought somebody had hacked the HP site and planted a phony story for laughs.

What's the world coming to when major technology players can't even succeed at being "also-rans" in the Tablet space?

Marc Andreessen probably has the right answer in his essay Why Software Is Eating The World:

1. The software is where the money is
2. The software runs "out there" in the cloud
3. The device end users access the software with doesn't really matter all that much to the service providers

That leaves Tablets in a very odd space... End users want cool Tablets, but nobody besides Apple and a bunch of Android clones will bother to build them.  Sort of a replay of the PC world where extremely low profit margins led to the near impossibility of finding a well made PC... but what took years for PCs took months for Tablets.

I'm guessing that (just like PCs) Apple's iPad will continue to be a high quality device (which you'll pay more for), and there will continue to be dozens of indistinguishable Android Tablets for about half the price.  Maybe Google's Motorola Mobile division will be the exception... but probably not.

Interdependent Tasks

Sam manages Bob, Barb, Brad and Bill, and one of his many responsibilities is to review and act on their requests for vacation.

The Vacation Approval process is very simple:

1. The Employee initiates the Vacation Request
2. The Manager reviews the Vacation Request and renders a Decision
3. The Employee is notified about the Manager's Decision

So far so good... but implementing this process gets complicated pretty quickly.

Sam can't really (in good conscience) make a Decision about any Vacation Request in isolation.  Only one Employee can be absent at any one time, so every Decision that Sam makes potentially effects all of the Pending Requests.  To be fair to everyone, Sam needs to take into account all of the Pending Vacation Requests before rendering a Decision on any of them.

What looks at first glance like a simple Request Approval process has revealed itself to be a Parallel Request Approval process.  The "Make a Decision" Task for one Vacation Request is linked to all other pending Vacation decisions.

Examples like these are what makes implementing "real world" processes hard.  Processes seldom execute in a vacuum, and work done within one instance often influences other instances.  Participants often have to consider multiple Tasks together, rather than performing each task in isolation.

Some of you are no doubt awaiting in breathless anticipation for me to reveal an elegant solution for dealing with Interdependent Tasks through clever BPMN modeling... but alas, I have no canned solution.  When I encounter these situations I fall back on custom coding with varying results.  My only advice (today) is to spot these cross-task dependencies early on in your projects and deal with them as best as you can.

Scratching the Programming Itch

My wife Teri has been using Scratch with her students for quite awhile, and every time I take a look I just get more impressed at where it's leading...

Google's App Inventor is a good example of how Scratch is escaping it's play pen... It let's you build apps for your Android phone "without writing a line of code" ;-)

My favorite Scratch extension is BYOB (Build Your Own Blocks) which elevates scratch from elementary programming to something quite a bit more serious by adding procedures and lists.  This is a fantastic example of how adding in a few simple constructs can greatly improve the power of a programming tool without making it any more complex for the new users.

Honorable mention certainly goes to Waterbear - a pure JavaScript blocks editor that points the way to Browser-Based Scratch (like) programming.  Great work.

Block programming does indeed become tedious when building large programs, and good code editors can catch virtually all of the syntax errors that blocks prevent... but I think it would be a mistake to discount the approach.  Blocks have proven to be a great way to get started in programming, and with the proper blocks most folks might not ever need much more.