Workflows or collaborative editing?

Workflows are often requested in enterprise software. They cover areas such as publishing articles in a CMS, sales- and purchase order approval, online registration, shipment, subscription and cancellation. Among many other things. You probably go through several workflows in the course of a work day.

Why do we have workflows? For many different reasons:

1. Ensure that things are done in the right order. No shipment before payment. No shipment before all items are in stock. No unwrapping of presents before the tree has been lit.
2. Ensure the right people do their part of the job. For instance, making sure an article is reviewed by PR before being published. Or that each elf makes his part of the wooden truck.
3. Ensure the right people are informed. For instance a mail is sent to the Finance dept. when a payment is overdue. And Santa is notified when little Molly misbehaves.
4. Make sure that people don’t overwrite each others changes. For instance the check-in/out mechanism in most content management systems. And making sure that you and your wife don’t both buy a gift for aunt Christie.
5. Document that standards and procedures are followed to comply with rules and regulations.

Sometimes, workflows are put into place by default, by habit, or by convention. To publish even the simplest change to an article in a Microsoft SharePoint publishing site, for example, you need to perform the following manual actions:

1. Check out the article
2. Edit the article
3. Save the article
4. Check it in
5. Click Publish
6. Fill out the form
7. Click OK.

That’s ridiculous! And that’s just the standard workflow before a workflow-aholic business architect has added extra steps and flows. What we should be doing instead is simplifying the life of software users.

Let’s think a bit about two categories of workflows: First, those that model the business processes closely, and secondly, those that are applied because of habit, by default or because of fear of being accused of not being in control of our processes. The first category deserves our attention and Christmas Love. Workflows in the second category should be replaced by something more efficient.

Speaking of which, what if, instead of a workflow involving check in/out, your CMS worked like Google Docs, allowing any number of people to work simultaneously on the same document while seeing each others changes updated live on screen? What if you could have the same feature in your backend systems, allowing you to see the other users’ cursors as they type?

If someone makes a mistake (and some one will!), there’s a complete history available. Do you remember the disbanded Google Wave? There was a slider that allowed you to drag a slider left and right and magically watch the letters disappear and reappear in the order they were added by all users. One place you can see this in action is on collabedit.com. Try typing in some text then go to the history tab and drag the slider. Pure magic!

The technology that did the magic in Wave was acquired from Etherpad.com back in the day. Wave didn’t fail because of the real-time collaboration technology but for a lot of different reasons, one being lack of integration with email. After Wave was abandoned, Google open sourced the components that allow for real time collaboration. They are free for anyone to implement in a CMS, or in any web app.

I think it’s time to abandon the old check-in/out workflow. With components like signalR, a simple Wave-like HTML editor can be done in 30 lines of C# code and 60 lines of JavaScript. In other words, it’s ready to be put into production to replace your CMS publishing workflow today. Sumit Maitra posted a demo of these concepts.

One additional benefit is that the collaborative editing paradigm, when implemented right, caters for at much nicer User Experience. Having to ask your colleague to unlock a file or document (while she’s on vacation) is time consuming and frustrating. Fluently typing while she is working on the same document, article, product, campaign or whatever, is good User Experience to me.

To conclude, workflows that model business processes are the important ones. They need our love and attention. Workflows that exist because of an old technical limitation, or because it has become a habit, need to be reconsidered. Workflows that make you comply with laws can perhaps be re-thought and simplified. Which of your workflows fall into which category will have to be assessed case by case. But chances are, if any of your systems rely on the check-in/out mechanism, there’s an easy win right there.

Merry workflow-ho-ho!

PicoFX–a dogma for simple frameworks

It’s really easy to be persuaded by a large framework that does everything. Who would want to tie your shoelaces together by choosing a framework, say an ORM, that does not have support for … say enums? (Sorry, EF I couldn’t resist picking on you.) Who can say no to log4net. After all, it’s comprehensive. It can log messages to files, rolling files, databases, event logs, toilet paper and the Times Square Billboard at rush hour?

NHibernate can do ANYTHING you’d want from an ORM. Now that the current EF CTP supports enums, it’s getting there too. But all the extra functionality comes at a price that you’ll have to pay eventually: Added complexity. Listening to “The Rise of the Micro-ORM with Sam Saffron and Rob Conery” on Hanselminutes, I was inspired by their thougths about going back to basics. Both their ORMs support only basic ORM stuff, but the complexity is way down –- and performance is so much better! Rob made me realize that SQL might just be the ideal DSL for writing queries. I had some of the same ideas when back in 2006, I wrote a simple closed-source ORM called Matterhorn. It was a response to the unnecessary complexity that NHibernate 0.3 introduced in my apps. Back then, when I tried to explain the pain points I had with NH, the reaction I was most often met with was “That’s odd. I haven’t had any problemt with it.”

So Micro-orms to me is great news. I like Dapper, Massive and PetaPoco.  Orms are just the beginning. In fact, I think we should expand the notion to “Micro frameworks” to cover all kinds of frameworks from databases to service busses, from IoC containers to rest apis.

The term “Micro framework” might sound a little too much like the Microsoft .NET Micro Framework. So let’s instead go for something even smaller … what about PicoFX?

A dogma needs strict rules. So here are the rules that a framework or api must respect to be a PicoFX:

• Max 1000 Lines of code (excluding Unit tests)
• Only one code file that the user can include in any project
• No dependencies except the .NET BCL
• Must have open source license
• Fully unit tested

I challence you to take a look the framework that you wrote. Rip it apart like Rob Eisenberg did with Caliburn. Take the crucial bits and leave the rest out. Boil it down to under 1000 lines. Is it possible? Then you’ve managed to distill the essense of the framework and leave the fat to the dogs. And chances are performance is improving too.

That should be simple enough, right? Kind of. Once the first version is out and the users start requesting additional features and you have all sorts of great ideas as well, trouble will start brewing. Can you add features and stay below 1000 lines? It’s tempting to add the killer feature thinking that 1156 lines won’t hurt. It’s only a bit more than 1000…

Every feature represents an additional tax, that your users will pay. What if you start taking out one feature every time you add one, respecting the 1000 lines limit? You won’t be 100% backwards compatible. That may hurt some. On the other hand, you’ll be keeping your promise of a simple framework that stays simple.

I’d better chip in and start taking my own medicine. I hereby submit PicoIoC, a 280 line fully functional IoC container. It’s heavily inspired by Autofac and supports registration by type, by lambda or by instance. Automatic lifetime handling means PicoIoC will deal with calling Dispose() if your class implmenets IDisposable.  It support abstract factories and Lazy<T>. Yak yak yak. Check it out yourself. I promise you it will stay

I can’t wait to see the PicoFX versions of your framework.