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.