Will Workflow Solve the Software Crisis?

20 years ago, software legend Brad Cox (Objective-C) described the emerging software crisis and advocated a fundamental change in the way we approach software development.


Hardware engineers have discovered how to reuse each other’s efforts; to stand on the shoulders of giants, instead of their toes.  We’re already face to face with the software crisis – the awareness that ambitious software systems are generally too expensive, of insufficient quality, hard to schedule reliably, and nearly impossible to manage.  It is time for a revolution in how we build software, comparable to the ones that hardware engineers now routinely expect about every five years.

– Brad Cox, Object-Oriented Programming, an Evolutionary Approach, 1986.

Each time a new development paradigm surfaces (usually from Microsoft), I start to wonder all over again if we as software engineers might finally realize the dream of true reusability that hardware engineers have enjoyed for decades.  Of course, each time a new paradigm surfaces, it also tends to introduce radical new tools and methodologies and we end up throwing out the old to make room for the new.  At least for hardware engineers, the fundamental platform (the circuit board) doesn’t change.  For us, the new programming paradigm is usually accompanied by new development platforms that are integral to any solution using the new techniques.  And so we never seem to build on work that was done before.  Instead of standing on each other’s shoulders, we stand on each other’s toes, continually reinventing.
The latest paradigm shift is “workflow”, and it again promises to yield higher productivity through encapsulation of business processes.  I started thinking about what might be different now that could enable the kind of reusability that Mr. Cox envisoned back in 1986.  What does Windows Workflow Foundation offer that prior initiatives lacked that might facilitate rather than hinder the construction of universally pluggable components?
The ability to embed the WorkflowRuntime in any .NET application is a big step in the direction of providing a universally available “virtual circuitboard” for snapping together an ever-increasing variety of software integrated circuits in the form of workflow activities.  It’s not just the WorkflowRuntime class that offers this promise, but the extensive support that WF provides for running workflows within those hosts.  Also, Microsoft has done a good job of pre-populating the built-in set of activities that enable us to develop non-trivial workflow solutions out of the box.
In the coming months, I’ll be exploring this concept of workflow-as-software-ic in greater depth by focusing not just on the mechanics of developing workflow solutions, but on composing complex workflows from more primitive workflow activities.  Since my “day job” is centered around information worker productivity, this exploration will naturally involve smart clients, forms and collaboration.  Can you say Office 2007?
Stay tuned.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.