Open Source + User Builders = Great Products

I read this story over at npr.org this morning:

"Before Jonathan Kuniholm had a tour of duty in Iraq, he worked for Tackle Design, an industrial design, research and development firm. After that tour, he was missing part of his right arm — which he lost when his Marine patrol was ambushed near Haditha.

When Kuniholm returned to his design shop, he brought along three prosthetic arms given to him at Walter Reed Medical Center — the same body-operated hook many veterans have used since World War I, a shorter utility prosthetic, and a new, state-of-the-art myoelectric arm. Each one had its drawbacks — and when Kuniholm and his Tackle Design colleagues disassembled them, they quickly concluded that they could improve on the designs. They founded the Open Prosthetics Project, an open-source collaboration that makes its innovations available to anyone. And Kuniholm signed on with Revolutionizing Prosthetics, an initiative of the Defense Advanced Research Projects Agency, or DARPA."

There's an important lesson here for every company that builds products:

1. Users are a better judge of what your product should do than your developers.
   
2. Users who have the skills to build your product themselves will improve your product if given the chance.
   
3. If you don't let your User/Builders improve your product, your product won't be as good as it should be.

Viva Las Lunas!

It's taken me a few days to figure out what I wanted to write about the 40th anniversary of the moon landing... I was 12 years old - and the moon race played a very prominent role in the world view of that nerdy 12 year old.

I remember an evening shortly before "One small step" - I don't remember if they'd already landed or if it was between the touch-down landing and Neil Armstrong's famous descent of the ladder - but I was outside with my father and looking up at the moon. Tom, my father, was talking with his friend "Mr. Hahn" about the landing, and "Mr. Hahn" asked me if I was going to watch it on TV that evening.

For some reason, my response was "No". Perhaps I was just being a contrarian pre-teen, but I definitely remember him reminding me what a special occasion this was. Humans had been standing on the earth looking up at the moon in the sky for thousands of years, but never before had someone been standing on the moon looking back at the earth.

"Mr. Hahn" was a rather profane man, born into the wild-catter-oil-patch culture of West Texas and not predisposed to poetry - but he shook me out of whatever funk I was in and I went home and watched Neil and Buzz with rapt attention.

What amazes me to this day is the undeniable fact that at 12 I was already jaded by the space program before the moon's first footprint. I've been going through my stash of memorabilia weeding things out lately, and I came across a folder bulging with NASA photos and articles and sketches of my own plans for space ships. There's quite a lot of "Star Trek" along with the NASA glossy photos - obviously I was hooked on space.


When I was 9 years old, we were all going to live and work in space. The first astronauts were super-human test pilots - but that made sense. They were blazing the trail that we were all going to follow. Space was not going to be the sole domain of multi-Phd toting eggheads - "Normal people" would be there doing all the things that "normal people" do.

NASA was an agency of innovation. They were constantly unveiling new rockets, capsules, rocket planes, etc. It was always new and exciting.

Perhaps the Apollo One disaster was the beginning of my disenchantment. The inferno that killed those 3 heroes was due to sloppy workmanship, not technical complexity. Even as a 10 year old I was sickened. How could anybody associated with the space program be sloppy?

After the last moon flight it just got worse.

Skylab was a disaster on launch - Solar panels ripping off during launch due to poor construction. The shuttle - supposedly cheap and reliable - just a ticking time bomb of compromises that had more to do with keeping the money flowing to contractors than to accomplishing anything worthwhile.

NASA (the agency) has no luster left to lose - not the people. The people are great. The agency NASA should be scuttled and its responsibilities parceled out to more focussed agencies: NOAA, DARPA, DOE, etc.

My space heroes are now Elon Musk and Robert Bigelow. These guys understand that interest in space has little to do with science - it's about adventure. If it's not exciting, then why go?

NASA's plans for a moon base are about as exciting as the Antarctic Scott Base. How many people do you know who are dying to visit Scott Base? (How many have even heard of it?)

I know many people who would love to take a cruise to Antarctica to see the fjords, glaciers and penguins... but who wants to go sit in an over sized high tech igloo? Compare NASA's 2009 vision of a moon base to their 1970's vision for a space settlement and you'll see how boring the future has become.

Vegas baby... the moon doesn't need a "base", it needs a "strip". Vegas is a city that never should have been - a gaudy exciting bubble of sex, sin and gambling in the middle of absolutely nothing. If Vegas didn't cater to hedonism, there wouldn't be a Vegas.

Musk and Bigelow understand that. They're serious businessmen, and they're following the money that's available now (COTS, etc.), but I think they know that the NASA gravy-train and communication satellites are only going to take things so far. The moon's going to remain forlorn until Cirque du Sole has a lunar venue where they can perform.

40 years ago something truly amazing happened on the moon. Let's hope that 40 years from now we don't have to look back 80 years for inspiration.

Get the Words (and Notation) Right

Dan North (the chief evangelist for Behavior Driven Development) loves to say:

"Get the Words Right"

In the context of creating software if you don't know what somebody wants you to build - then you can't build it for them... That statement is true for lots of contexts but let's stick to software for the moment.

If the person who wants something built uses terms that you don't fully understand, then you'll have to translate those terms into something that you do fully understand. Translation is never perfect, so you're bound to screw up something. When you are ready to explain what you're building to the client (to confirm that you are in fact building the right thing) if you use terms that the client doesn't fully understand, then they'll have to translate your words - and they are likely to misunderstand what you're building.

Sometimes a 3rd party will be on hand who understands both the client's and the builder's terms (I do that a lot)... but then you are dependent on the translation skills of the 3rd party. The good news is that both you and the client can blame the 3rd party, but your software still stinks.

Dan's solution to that problem is to spend more time up front agreeing on a common vocabulary between builder and client... with a definite prejudice towards adopting the client's vocabulary whenever possible.

Seems pretty much like common sense, but it's very hard to actually do it.

Many programmers just don't really want to understand their client's businesses... they're excited about programming, not business. Business concerns are mundane and boring compared to the challenges that they face when creating software... in their opinion. Many business people are just as bored by technical details as programmers are by business details.

It's hard - but in truth it's the easiest way to succeed. When everyone is on the same page building projects are actually fun... and the "buildings" are really fun to "live in".

In the Business Process software domain, we have a common notation for expressing the "flow" aspects of processes - BPMN. BPMN is relatively simple to learn and it has proved to be a very effective means for Business and Programmer to communicate about the "flow" aspects of their business processes. Unfortunately, BPMN isn't good at all when communicating all of the other aspects of a business process (data requirements, routing rules, etc.) but it's a good start.

BPMN is Notation rather than words... but Dan's point is hugely relevant - you have to get the Notation right.

I've worked with BPMN for a few years, and I think the Notation has elements that just aren't right. They don't convey the meaning of the symbol to most Business people.

Here's my least favorite symbol - the Multiple Instance Activity:

When you see this symbol, you are supposed to know that many copies (instances) of this Activity will be performed at the same time. You "know" this because there are those two little parallel lines on the Activity - They're parallel to each other, so of course that means there are parallel Activities taking place.

I am not a Business person, but I doubt that many would describe Activities-That-Happen-At-The-Same-Time as parallel Activities. If someone out there knows of a study that proves me wrong, please tell me.

I think a better symbol would be something like the following:

With this symbol everyone can see at a glance that Multiple-Things-Are-Happening (hopefully at once). I'd also add some indicator of the number of "Things"... although often that's only determined when the process is running.

I suspect that the current Multi-Instance symbol was chosen because it is easy to draw by hand. Fair enough... but I find that most of my hand-drawing is done on white boards, and I almost always draw something that looks a lot more like my proposed symbol.

Fortunately, with the current state of BPMN editors it is usually pretty easy to swap out the "official" notation's symbols for your own... There are much bigger problems to solve in the realm of conveying Business Requirements to Programmers than this little icon - so please don't waste any time lobbying for it to change. I'm just using it to illustrate the point:

Words Matter - Notations Matter - Diagrams Matter

Pictures are worth a thousand words, so take the time to get the picture right before you start building your next project.

The Toilet Paper Replenishment Process

Don Norman has an excellent blog posting about the poor design of many Toilet Paper Dispensers - focusing mainly on the poor algorithms that we simple humans use when given a choice of which roll to use from a multi-roll dispenser... Multi-roll TP dispensers prove Don's thesis that many every day things just aren't designed well. I had read Don's book and seen his blog long ago, but it came back to mind when I encountered the following in a bathroom in Stanford University's Terman Engineering Building...

No less than six partial rolls of toilet paper perched on top of a standard two roll toilet paper dispenser.

Obviously Don is right about the design of the dispenser itself... Given the choice of which roll to use we'll pull sheets off each. But obviously there's something more at work here: The process for refilling the dispenser is suspect.

I suspect the process is something like the following:

Check the dispenser each day. If either of the rolls is less than 1/4 full
replace it with a full roll and place the partial roll on top of the dispenser.

The objective of this process is to make sure that there's always plenty of toilet paper available... Obviously you don't want to run out.

My guess is that the partial roll is left on the dispenser in the hopes that folks will use it - This is much better than throwing it away, and given frugal college students I'm surprised that the partials aren't disappearing.

The flaw in the process seems pretty simple... "Enough Toilet Paper on Hand" doesn't take into account the partial rolls. Instead of basing replacement on the size of the rolls installed in the dispenser, it really ought to be based on the total amount of tissue on hand - the rolls in the dispensers plus the partials.

At first glance this appears to be a classic example of mis-stating the objective of the process. The janitor who refills the dispenser has been told something like "No roll on the dispenser should be less than 1/4 full". The real objective should probably be something like "There should always be the equivalent of a full roll on hand".

Having restated the objective: What if you ended up an "equivalent full roll" made up of sixteen partial rolls? That certainly wouldn't be acceptable to most folks.



Returning to Don Norman's point - the design of the dispenser itself is really at the heart of this "process" problem. The process for refilling the dispenser is overly complex due to the poor design of the dispenser itself. Try as we might to give proper instructions to the janitor, success is going to be highly dependent on the janitor's judgement on whether or not enough toilet paper is on hand.

What can we learn from this example?

If a process that should be simple isn't, then look beyond the process definition: It may be better to buy a new dispenser than to figure out how to refill the one that you have.

---

UPDATE:

---

Prompted by the comment of a good friend and Stanford Alum I delved a bit deeper into the conundrum and sadly discovered that this is both a Process and a Design problem... In another bathroom at Stanford I discovered the following shocking sight:

The superior design of this multi-roll dispenser has been thwarted by the installation of two such dispensers... The point of the design was to eliminate choice (thus simplifying the refill process) - introducing a second dispenser nixes that advantage... and as you can see the "refill process" is still needlessly removing partial rolls.

Such a thing would never have happened at my alma matter (Rice University) ;-)

Changing planes while in the air

I fly a lot... way more than I ever thought I would... and I can say with some confidence that it's sometimes much harder to get from point A to point B than you thought it would be.

My home bases are Austin Texas and Santa Fe New Mexico, and neither is an airline "hub". Airline hubs are those wonderful airports where you can fly to and from a lot of places (non stop)... Neither Austin nor Santa Fe, as I just said, are one of those wonderful places.

Virtually every trip that I take requires changing planes. I land, scurry to another gate, and take off again. "Scurry" is often a nice way of saying "run flat out as fast as I can". For those of you who don't fly often, you may not realize that most flights board 30 minutes prior to departure, so if you think you have an hour between flights, it's really only 30 minutes... even a minor flight delay can turn "plenty of time" into a missed connection or lost baggage (if you are brave enough to check your bags).

Each trip that I take is (in a sense) a process. I fly from home to an airline hub, then I fly from that hub to another airport. On rare occasions I have to fly from the second airport to a third... You get the idea. On each flight, I am sitting along with a couple of hundred other people who are each taking part in their own similar processes. As long as all of the planes that we'll use are on time (the plane that we are on along with all the planes that we'll connect to) all of our processes will run smoothly. If the plane that we are on has mechanical difficulties and has to return to the airport, or if weather or some other obstacle keeps us from landing where we expected to, then our processes are all in a heap of trouble.




From a process design perspective the events that I have described are exceptions. We don't "expect" these things to happen, but we have to handle them if they occur. Some airlines have processes in place that work really well... other airlines... well... let's just say that I've slept on a bench in O'Hare airport and leave it at that.

Exception handling is actually pretty well understood in the realm of Process Design. With BPMN notation you can attach event handlers to Activities and model "what needs to happen" when something out-of-the-ordinary happens. Proper event handling requires a lot of thought... but in a sense it's a well understood aspect of programming that isn't specific to process engineering... and it's not really what I want to blog about today.

Let's go back to flying... This example is admittedly kind of absurd, but imagine that the airline changes their schedule while I am in the air. Let's say that the itinerary that I am on is now supposed to go from Austin to Denver to Chicago instead of from Austin to Dallas to Chicago. From now on, whenever I want to go to Chicago I will change planes in Denver instead of Dallas.

What I've described here isn't a process exception - it's a process change. The airline has changed the process of getting from Austin to Chicago.

For somebody starting a new trip, it's obvious that they will follow the steps of the new process definition. For folks who are already in the air on the first leg of the trip, there are two options:

1. Continue the following the "old" process steps until the process finishes - this depends on the airline keeping a flight from Dallas to Chicago until everyone in the air gets there.
   
2. Switch to the new process while "in-flight" - this depends on the airline re-routing the plane mid-flight to land at Denver instead of Dallas - or perhaps jumping from one plane to another as they pass each other.

Option number one is really safe. The old process is well understood and it's very clear where everyone will end up... we know we have enough gase to get to Dallas. Unfortunately continuing an old process until it is complete isn't always a viable option. Some processes take a really long time to finish, and it's unreasonable to carry on as if nothing has happened (sometimes for years) - the airline can't keep an unfilled plane waiting at Dallas.

Option number two - metaphorically changing planes while in the air - can be very risky to your in-flight process instances - the planes in the air may not have enough gas to get to the new destination, and it's quite likely that some of the passengers on the flight planned to get off the plane in Dallas. Let's not even think about jumping from one plane to another.

It's this ability to handle in-flight process changes that makes the implementation of a really good process manager difficult. Creating an "engine" that can execute a process definition is pretty straight forward... it's mostly a state machine.



Switching from one process definition to another while "in flight" can be a heap more complex...


Process improvement is a key goal of BPM adoption... When you figure out how to improve a process you want to be able to implement that change as soon as you can... but process change requires more that modelling the new process... you also really need to model the process of getting instances from the old process definition to the new.


For every possible step in the original process definition, you need to define the corresponding step in the new process.

If the correlation isn't exact (one process definition has steps that don't really exist in the other), then you must tell the process manager what to do. In some cases, an in-flight instance may need to "go back" and redo a "previous" step in the new process... or the in-flight process may have to perform some "transformation" steps before merging with the new process flow.




Unfortunately, BPM tools don't generally have explicit support for "migration" processes... it's generally left to the practitioner to figure out what to do with in-flight instances, and sometimes there's a rather painful transition when a new process definition is deployed. I'm sure this will change as BPM adoption increases, but in the mean time you'll have to build your own parachutes in case something goes wrong.

People Manage the Process?

Gerhard Basson has posted a very nice article Process-oriented Systems Paradigm for the Process Age over at the BPM Institute web site. I agree with almost everything that Gerhard says... but as usual one little phrase pops out and spawns a blog of my own.

Gerhard asserts:

"processes do not manage people – people manage processes"

I understand what Gerhard means... very clever word-smithing... but I squirmed when I read it. I know that I am splitting hairs here, but "manage" just isn't the right verb for the phrase:

"people verb processes"

That aside, I vehemently agree (as opposed to vehemently disagree) with Gerhard when he says:

"People will bypass and reject any system that does not help them perform work in a natural way."

It's always about the people... From the conception of the process to the implementation of the process to the running of the process to the improvement of the process... it's always about the people.

If we don't adapt our systems for the People of the Process Age we're not going to get very far.

Programming Language Sociology

Bruce Eckel shares his reminiscences about the dawn of C++ and Java in his blog entry: Why? Language Archaeology.

This is great stuff... Insight into the "why" C++ and Java are the way they are (from Bruce's perspective). My take-aways from this essay are the following:

• "Things" often make no sense because the requirements that dictated those "things" are no longer requirements
• People skills can be just as important as Technical skills

I really appreciate Bruce admitting that his opinions about Java are colored by his dealings with Gosling... Social aspects impact Technical aspects. How you feel about someone impacts your evaluation of their work. That is a hugely important thing for us to remember.

I was an early adopter of C++ and loved it... but I loved Java more. Was that due to Java's technical superiority?

Nope.

I loved Java more because it coincided with the Web... and the Web allowed me to collaborate with other Java developers in a way that I had never been able to collaborate with other C++ developers. The social aspect of this collaboration is why Java trumps C++ on my "fondness scale"... Java had (and still has) a much stronger sense of community than C++.

The stereotype of the programmer nerd with poor social skills had a lot of basis in fact... but in my experience programmers really crave social interaction within a society where they feel comfortable.

My programming focus is now in the realm of Business Process Management, so the society in which I find myself is much broader than that of my C++ days. In my C++ days I wrote stuff for business people. Now I write stuff with business people. Huge difference.

Successful Business Programming requires a society where both Business and Technical people feel comfortable. That's tough to accomplish because the passions of those two camps rarely coincide...

Next time you're in a conference with both Technical and Business people, sit back and watch:

When the Business folks get into an animated discussion the Technical guys will be checking their Blackberries. When the Technical folks get into an animated discussion, the Business folks will start looking at their watches.

The challenge in business programming today is not about programming language features - it's about the social aspects of application development. We've got to solve the problem of engaging everybody in the development process. We need to fully engage the Business folks to make sure that we build the right things, and we need to fully engage the Technical folks to make sure that the things are built right.

Compared to the real challenges of business programming, agonizing over whether or not to include the "new" keyword in Java is seems positively "quaint". Bruce's recollections are a fond trip down memory lane for me... but lets not get stuck in the past lest our descendants look back on our concerns as "quaint" too.