Why Developers Hate WF and Why They Should Get Over It
Microsoft does an amazingly good job of making technology accessible. What I mean by that is that for people who are not necessarily “technologists”, custom applications are still often within reach. We’ve all seen this in the wild.
It might be that Access database that won’t die, created by that guy in marketing in 1998. Or maybe it’s that huge VBS Excel macro that Sales Guy made that forecasts revenue for the next 20 years and affects your stock price? Perhaps it’s that SharePoint 2007 “application” that HR made to in-process resumes.
Programmers hate these things, and not just a little bit. We hate them in the core of our being, and here’s why:
- These things are hard to maintain
- Often, they become our problem after they find some traction
- These solutions often add tremendous value without being done by the all powerful software developer
Hey, wait a minute! What was that last one?
It’s About Business Value
That’s right, cobbled up technology solutions like those mentioned are often extremely easy to produce and provide value to our organizations without the cost of submitting work into a software development team.
I am not for one moment pretending that these solutions are well crafted, easily maintained, or a smart long-term play. I am saying the value of Application Right is often less than that of Application Right Now.
Of course, I am not advocating running your enterprise on Access and VB Script, but sometimes these are the right tools for the job. Well, maybe.
A Brief History of Enabling My Mom to Write Code
Microsoft pioneered drag-and-drop development with Visual Basic. I remember creating applications in VB 3 circa 1993 that did similar things to what we do with forms-over-data today.
People who never considered themselves programmers picked up VB and started making things. Later, we got similar functionality embedded in products. Excel, Outlook, Word, SharePoint, and other things got very drag-and-droppy for creating small utility applications that the HR intern could figure out without calling IT.
Most of this drag-and-drop functionality was focused on the UI. Meanwhile, many developers retreated to middleware and the services layers. “Let someone else figure out the UI”, they decried. “I will focus on the complicated stuff.”
Yahoo Pipes not only opened up backend processing for the masses, but it did so online. Now my mom isn’t just drag and dropping UIs, she is doing it with data feeds. Interesting development!
Where WF Fits
WF goes further by enabling developers to create applications with drag-and-drop support for business logic and middleware. This lets non-technologists start working with things like services, business logic, and data instead of just buttons and MessageBoxes.
So now instead of just exposing a button to the HR intern in SharePoint, we can expose an enterprise service. Or a long running, repeatable business process.
Does this deprecate the value of a highly technical software developer?
Of course not! No more so than the advent of drag-and-drop UIs meant fewer developers. And there are certainly more software developers working today than in 1990.
WF simply allows us to create applications that expose a slightly lower level of abstraction to our business users, empowering them to create solutions using the components of our labor.
Is WF a legitimate programming tool for devs?
Yes, but like anything else, it is just a tool. And like most tools, it can be wielded as a weapon.
WF is more likely to be a tool for your RAD solutions or for enabling your business users in some way. No one says we need less text-based code.
Think of other widgets you make for your business customers. Are you likely to use them to solve your own problems as a developer? Sure, why not?
But, Drag-and-Drop Development yields poor quality.
It sure does when the things you are dropping are of low quality to begin with. And the thing you are dropping onto needs to be a solid surface as well.
This means that if you are going to WF enable your applications, you’d better know what you are doing. The WF Activities and WCF services you put out there in the wild need to be solid, because now business users are going to be talking to them and using them to compose applications you haven’t conceived of yet.
You can’t depend on the client playing body guard for your service or WF application.
The Next Level of Abstraction
At the end of the day, WF is just one more layer of abstraction for composing applications. A WF application can be pretty elegant as an enabling technology.
Will big piles of un-maintainable crap be built with WF? Yes.
Are big piles of un-maintainable crap built with elegant programming languages? You bet.
This is how the industry evolves: one level of abstraction at a time. WF is just a natural evolutionary step.
I, for one — having worked both in BizTalk 2004 and SharePoint 2007 — have yet to encounter a business user that actually accepts Microsoft’s “so easy, even your business users can do it!” pitch as a point of personal responsibility. What it usually — and VERY unfortunately — turns into is, “if it’s supposed to be that easy for me, just imagine how much easier it is for a programmer” right before a boatload of custom requirements that either intentionally duplicate or intentionally contravene the functionality of the platform get sent down the pipe to us.
To wit: If I am interested in WF, I am interested in it as a tool for my crafting. If I am not interested in WF, it is because I do not believe that it will adequately fulfill a function for me at this time. And if I am afraid of WF, it is because it is a spanner which my stakeholders, intoxicated by PowerPoint and high on foils, are adamantly demanding is really a cog that absolutely belongs in the works they have commissioned.
Long live unmaintainable crap!
Oh wait…it will anyway.
The better question is how to better identify unmaintainable crap and convince the powers that be to replace it. But invariably, the code I’m most proud of has been depreciated. And what I’m least proud of is currently being used by a couple of million people around the world. Go figure.
As for WF. I think it has its place in the tool set. I haven’t had that need very often, but it does come around every now and then.
I think it all boils down to responsiblity. If I am a developer and business people are playing with it and manipulating the stuff then it’s no longer my responsibility!
I am not going to debug their crap and answer questions like “why it’s not working” or “what did I do wrong?” etc.
I think in the WF is for developers itself to make it easier to change workflow/business rules etc!
Take an example of CMS. Everyone claims it’s damn easy to setup and people decide to use it so that they can “manage” the content myself. If they really “manage” they end with reds/whites/blues in the site and make it ugly! Then they find a designer to redo the content for them!
So although the whole idea of DIY is tempting, it’s not going to work, you can’t expect everyone to be responsible.
The title of this post is deliberately provocative, but as a result I think it misses the point about WF.
I was interested in WF (and remain interested in where it goes next) _precisely because_ it promised to give an easy-to-grasp UI to non-programmers to allow them to create custom business logic by plugging together components.
I was disappointed by it _precisely because_ it failed to deliver this. In all the useful demos I’ve seen, and in all attempts I’ve seen to make it work in practise, it was necessary for the end user to crank out some code-behind in VB or C#.
And the headline pitch you describe – “accessible to non-programmers” – completely collapsed when I spoke to the relevant folks at MS back in 1997. Here’s a blog post from Paul Andrews, PM at the time, that lays it on the line:
http://blogs.msdn.com/pandrew/archive/2007/01/16/how-does-windows-workflow-foundation-wf-compare-to-product-x.aspx
Key quote: “The workflow designer is best suited to developers, not business analysts.”
So what good is it? I’m already skilled in using real programming languages, and in return I can depend on proven techniques for code reuse (methods I can call, classes I can inherit, generic types I can instantiate, etc.), and I also get a state of the art debugging experience. If I try using WF, I get to use “experimental” code reuse features, and I get a crummy debugging experience.
Unless it opens up some aspect of the development process to non-programmers, deskilling it somehow, it has no purpose. Users who already know how to code will be better off writing elegant, readable code.
So I hope that this changes or is already changing for 4.0.
Hi there. I really enjoyed most of the article, especially the parts about how these non-programmer created applications create a lot of business value. I think developers can lose sight of that when faced with the incomprehensible maw of an unwieldy app.
The only criticism I have is that you never define the acronym “WF”. Based on a tentative google search, I assume you mean “Workflow Foundation”, but I’m not a Windows developer, so it’s hard to say. Most of your target audience already knows what WF stands for, and for those that don’t, spelling it out doesn’t hurt.
Anyway, thanks again. Sorry I can’t comment on the actual point of the article, but I feel the introductory portions are spot on. 🙂
@jim – Yes, Windows Workflow Foundation. Sorry for that noob error.
@daniel – OK, that’s totally fair. What about the WF enabling inside SharePoint? Do you think that is beyond the HR intern? I don’t think the Visual Studio designer is for BAs, either.
I know this is a stupid question, but WTF does WF stand for?
I totally agree with Daniel, WF is a horrible tool for devs and too complex for Business Users. I have not used SharePoint Designer, but I can tell you that building a workflow of any real complexity in Visual Studio will cause you to run into undocumented “features”, make simple things hard and generally make you want to never use the technology again.
#3 is not why we hate them. It is because of the perceived value. If you look at the total cost, total ROI and typical duplication it would have been better for the org to hire competent developers or additional competent developers. (case in point – See this months VS Mag “Coding Catastrophes) Sadly, many developers are not as qualified as super users.
I only looked briefly at the Sharepoint workflow features – long enough to get the impression that they had solved the problem a different way, with something more boiled-down and targeted to their users’ needs, which makes perfect sense. But what does this tell us about the reusable WF designer, or the runtime model it is based on? I’d say: not much.
I think a nice example of a highly targeted workflow designer from Microsoft is the Outlook Rules Wizard – it’s a very nice, self-explanatory dialog for creating a filtering algorithm. If you want to expose configuration flexibility that has algorithmic decision-making power in it, that’s the kind of thing to go for, I think. Start with a clear problem definition, insert flexibility into it where necessary and guide the user through the resulting pattern, letting them fill in the blanks.