This month, I want to talk about Windows Workflow and what it means for the state of .NET development (in my experience and, of course, in my opinion). Before the release of Window Workflow (WF for short because WWF means something else entirely already), there were several avenues open to developers to make things work with a workflow feature.

The primary choices were to build your own or leverage the workflow capabilities in Biztalk. Both of these proved pretty problematic since the average developer was not experienced with building this kind of system and it's non-trivial to get it right. However, it was still a very common choice that many companies are still living with today. As for leveraging Biztalk, that was a much better time-to-market solution, but the licensing costs were hard to justify to an organization that was going to leverage only a fraction of the functionality, yet would still have to pay the full cost of licensing. I can recall numerous discussions about the pros and cons of these choices and they underscore the real need that WF fills in the market. The problem is that it is not yet a plug-and-play component.

There is a learning curve to using the WF, which means that in some cases developers are coming away thinking that the old choices may still be better. My advice would be to go back and have another look. Once you get past the warts and understand the initial steps to making WF work in your project, you most likely won't look back. This does again, however, underscore the message to Microsoft that I hope we can deliver loud and clear: the most likely use cases have to be simplified and made to work easily. Hearken back to Web services. Many people decried the oversimplifications and dumbing down that the generated WSDL represented, but it made the .NET implementation of Web services a runaway success. Developers are smart and they can figure things out, but who has time. On both commercial and internal business projects, the mantra is and will remain, "Time-to-market, time-to-market." Ship or die. Look at consumer markets, Web site usability design, and even developer components, and you'll see in all these categories great efforts to make things simple, not simply to capture dumb markets, but to capture consumers in all these spaces that have better things to do with their time than plumb the depths of your thoughts and thereby make your pile of code work in their world.

The lesson that I take away is that I would rather have a product with eight out of 10 possible features that work well and are usable (easily) by me, than have a product with 10 out of 10 possible features that require me to jump through hoops to make use of it in my project. It's time that usability for developers was back in the driver's seat.