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.

Good Engineering != Good Design

This thought-provoking statement grabbed my attention...

"Most tech products—heck, most products in general—aren’t as good as they can be because they’re put together by the people with the technical knowledge required to build them."
Jason Snell, Macworld.com

Jason makes some really good points in this article... Go read it ;-)

Artists (and programmers) hate negative feedback

If you really want to piss off an artist, just tell them how their painting/sculpture/etc. could be improved.

The best possible reaction that you'll get is a politely disingenuous "Thank you"... More likely you'll get some form of "Mind your own business" delivered with various levels of hostility based on the strength of the artist's self-esteem.

The creation of art is intensely personal... Art is an extension of the artist - created primarily to satisfy the artist's need to create. Art is presented to the public - not shared with the public. The artwork may be sold - but it always belongs to the artist.

What does this have to do with Programming?

For many programmers - Programming is their Art... and that's the root of many of the conflicts that you will have with programmers.

There's an anecdote about Frank Lloyd Wright: The story is that he attended a dinner party in a house that he had designed, and before leaving he had rearranged the furniture back to his original plan. Wright couldn't let go... The house was held hostage to his vision rather than released and allowed to become a home. Wright liked to preach that "Form follows function" - but in this case he totally forgot the true function of a home.

When you have to provide negative feedback to a programmer - focus on conveying the big picture: What do you really need? Instead of focussing on how the current software does not meet your needs, challenge the programmer's inner artist to create something that will fulfill your needs... You'll probably be much happier with the results.

Process Manager Interoperability - Wf-XML

Scott Francis sent me a snippet from a recent Keith Swenson blog posting on Wf-XML...

I've been looking for a standard like this... Process Folks have been pretty focused on Process Definitions that can be executed on any Process Manager (Process Portability), but in my day-to-day it seems a lot more important to insure that Process Managers can operate with each other...

Specifically, I want to be able to incorporate a Process that is running on one Process Manager as a Sub-Process of a Process that is running on another Process Manager. I want to be able to start the Process, Monitor the Process, and get Information back from the Process when it completes.

Much as we might like a world in which there is only one Process Manager, this just isn't going to happen. Consider the Java app server world... Despite corporate attempts to mandate the use of only one Java app server you still find a mixed bag. Once a WebApplication is developed and deployed on one flavor of Java app server it's seldom migrated to another. It's just not worth the expense or the hassle - even though migration might be relatively straight-forward.

In the Process World we should be able to take full advantage of previously deployed Process Applications regardless of their BPM platform. If an application has been developed with an embedded jBPM Process Manager I should be able to incorporate it in my Lombardi solution. If my Lombardi implemented Process can be used by a wider Pega implemented Process, then that should work too.

Wf-XML is an attempt to make that happen... I haven't had time to delve into the details, but the concept is right on the mark.