In general, I like Jay Cross’ writings. While I have never personally met the guy, I find that his articles usually have something interesting and sensible to say. Which is why I’m so disappointed with his overly exhuberant fluff piece in e-Learn:
“For some, the work of the future will resemble an elaborate, personalized video game front-end that’s connected to the physical operations of their company.
Life will be simpler five years from now. We’ll be comfortable living in a world of organizations without bosses, computing without programmers, and webs without weavers. “
And the lion will lie down with the lamb.
All this bliss supposedly comes from web services. What are web services? At the root, web services are really just a better way for software developers to develop and maintain components of a large application or system. In the (really) old style of programming, (called procedural programming), there was no easy way to separate dependencies within software code. That meant if you changed one piece of the code it might have a ripple effect that broke things elsewhere and it was sometimes hard to predict in advance where those breakages would occur. In other words, modifying large programs was hard and took a very long time (and cost a lot of money). Then along came object-oriented programming. In this world, you could take a piece of the software and wrap it up in a kind of a package, or “encapsulate” it. With encapsulation, you write a list of all the communications (commands and responses, basically) that your object understands. Once that’s done, then you can change the code inside the object all you want, and as long as its methods of communicating with the rest of the software don’t change, then nothing will break. With software objects, modifying large programs is still hard (in fact, in some ways it’s harder, since object-oriented programming requires more expertise and skill than procedural programming), but it often takes skilled programmers a lot less time to do the job.
Web services can be thought of, in part, as a new wrinkle on encapsulation that makes it easier to keep the various parts of your program stored on different computers. And because web services also include some other nifty features (like auto-discovery, which lets one software component advertize to other components what it does and what commands and responses it understands), web services make it easier for programmers to create new programs out of pieces of the old programs much more quickly and easily, even if those old programs live on different computers supported by different companies in different parts of the world.
But here’s the problem: Web services only solve a few of the many problems that have to be solved in order to reach Jay’s paradise. The harder problems in designing software that really changes the world are always the ones that revolve around what the humans actually need the software to do. In order for applications to be able to help all knowledge workers throw off the shackles of command-and-control and respond in concert in real time, we need to have some idea of how human beings would work the way that Jay describes if only the software would create the necessary environment. This is a very, very, very hard problem. And web services do nothing to solve it.
Jay’s way of dealing with it is by gesturing toward emergent behavior, which is the notion that a system of independent agents (in this case, knowledge workers), can spontaneously develop organized positive behaviors without any clear directive or conscious cooperation:
Skeptical? You’re witnessing bottom-up decision-making in the swift turn of a school of fish but we’re not used to seeing it in business. MIT Professor Tom Malone equipped an audience with hand-held paddles whose position could be read by a computer. On the screen up front, he projected a flight simulator. A hundred people jointly took the controls of the plane and, against all expectation, flew the plane without a pilot and without a crash
OK, admittedly, that’s pretty cool. But emergence is a new, complex, and tricky idea that we only have the vaguest idea of how to create on command. Does anybody really believe that having a few dozen people in a room fly a plane together is equivalent to having a few thousand people all over the world run a profitable corporation? Does anybody have any idea how to get from the success at the first thing to success at the second?
So while I applaud Jay’s enthusiasm for new technologies, I wish he would take a chill pill and not wind people up about sexy ideas that are vastly easier to demo than they are to implement in the real world. I understand that he’s trying to get the whole “workflow learning” meme spreading as agressively as possible, and I support that. It’s a valuable way of framing performance support that may finally get non-trivial traction in the Enterprise. But really…
For some, the work of the future will resemble an elaborate, personalized video game front-end that’s connected to the physical operations of their company.
Bowling scores will be way up; miniature golf scores will be way down.
*Sigh.*
Gary Dickelman says
I just returned from the Training/Online Learning conference in San Francisco, where Jay Cross et. al. introduced Workflow Learning (WL). I sat in on a number of the WL sessions and contributed to one as a presenter. Subsequently, I chatted with a number of conference participants for reactions, which were divided pretty evenly, as follows:
> WL is noting new. Gloria Gery, the first “Workflow Learning Institute Fellow,” had nothing new to say. WL=Performance Support. In her presentations on the subject, she used her standard fare. What’s with all the hype?
> It was refreshing to see learning placed in a workflow context at an e-learning conference. While the concepts are not new, the e-learning community needs to mature far beyond where it is today if it is to add real value to organizations with respect to competency and performance.
The general consensus is that it was quite unnecessary to invent yet another term (WL) for what Gloria Gery articulated in 1989 (EPSS) and which has matured substantially to the present day. Jay Cross’s statement that WL is “EPSS on steroids” underscores a superficial understanding of how EPSS, and more correctly “Performance-Centered Design” have evolved over the past 15 years.
I take a dim view of building a straw man, then burning it down. If one is going to make a valid comparison, then one must rigorously and accurately document the comparative. The Workflow Institute simply failed to properly examine the extant literature on Performance Centered Design (PCD) before inventing the new WL paradigm.
PCD focuses on business (organizational) performance through human performance by applying three fundamental perspectives and their rich disciplines:
(1) Business / organizational process improvement
(2) Human factors (usability, diversity engineering)
(3) Information / knowledge architecture and management.
The PCD lifecycle more than subsumes the fledgling principles of WL. Further, WL has little to do with workflow or learning. Business process, not workflow (in the strictest sense) forms the context; competency and performance, not learning, are the outcomes. Calling these ideas “Workflow Learning” only serves to confuse the issues and focus the discipline on the learning/training community, further exacerbating an aleady ineffective history around supporting performance.
Learning technologists, while excellent in their craft, are provided little grounding in the engineering rigors of business process modeling, improvement, re-engineering and the like. Further, usability professionals, including human factors engineers, are much better equipped than instructional technologists to deal with issues of interactions and interface design. And the technology prerequisites for responsible PCD transcend the basic curricula and experiences of the learning technologies. Similar arguments can be made for information architecture and knowledge management. So why place the focus of WL on the learning community? Curious.
I do not wish to undermine the honest contributions that Jay Cross and the WL Institute made to the Training conference this year. But I fear that the exercise has further confounded our attempts to codify and normalize the EPSS/PCD literature. Why do we need yet another term for these ideas?
Regards,
Gary