On the one hand, this is pretty funny; on the other it’s quite sad.
I recently came across a post (which I will neither name nor link to) that introduced the typical argument for why people build workflow for SharePoint using SharePoint Designer (i.e. lack of developer expertise to build it in Visual Studio). This one was more eloquent than most and tried to present both sides of the issue. I thought it was pretty good…
…until I looked at the alternative solution the author recommended.
Instead of a Visual Studio workflow, which would have entailed *maybe* 40 lines of custom code (not counting the stuff Visual Studio auto-generates for you) the “solution” required:
· 26 lines of code in an InfoPath form
· Required the creation of an extra list
· 17 lines of code in a custom Activity, plus the XML required to make this available as an Action in SPD
· An SPD workflow with 7 steps, some with multiple Conditions
WTF? The “no code solution” is harder and contains more code than doing it in Visual Studio – the “code solution”. Somehow the author tried to justify it by saying that there was no custom code in the workflow itself.
Huh?
I’ll concede that there is a place in the world for SPD workflows. But this is an example of where that is not the case.
So, in case you’re wondering…here are some thoughts on when you’re going too far with SPD for workflow:
1. If your SPD workflow contains more than about 10 steps…it’s probably too much
2. If you have to create lists, libraries or fields/columns just to overcome a shortcoming in SPD…it’s probably too much
3. If you ever, EVER need to deploy the workflow anywhere but where it is developed, SPD is the wrong tool (yes, I know you can edit things manually…and it may not even be that hard, but it is asking for trouble)
4. If you might need to change the process the workflow supports once it is deployed, SPD might be a bad choice. (This one is highly dependent upon the complexity of the original workflow that you’d be editing)
5. If you need to edit the generated forms, you’re likely asking for trouble
6. If you need to create multiple workflows and chain them together in some Rube Goldberg contraption, you’re definitely asking for trouble
7. If you need to do real parallel processing (well, kinda, at least an actual simulation of it, see: http://www.mannsoftware.com/workflow/Wiki%20Pages/When%20Parallel%20Is%20Serial.aspx) or escalation of any type, SPD will give you headaches.
8. If you need any type of SDLC, or even simple source control, SPD can’t do it.
By way of disclaimer, yes there are certainly exceptions to each of these. Think of them like a scorecard…some are worth 1 point each, and some are worth 5. Total up your score. If you scored more than 3-4, you probably want to reconsider your “solution”.
SPD is a tool, and not a bad tool. It has its strengths. But like all tools, it also has its weaknesses.
The problem is NOT the tool. The problem is the usage of that tool. If all you have is a hammer, you treat everything like a nail. In reality, what you need is more/different tools in your toolbox.
I’ve used SPD for workflows and will continue to do so when appropriate; the key words there being “when appropriate”. “But all we have is a hammer” does not make its use “appropriate”
I’m not the least bit interested in a flame war here and will not take the bait if it is offered but this is a perfect example of why I rail so hard against SPD for workflow – people take the tool way beyond what it was made for and jump through a ridiculous series of hoops just to write a “no code workflow”.
Puh-lease.
Dave
[end of rant]
PS: Note that for all of this, I’m talking ONLY about SPD for workflow. Other uses of SPD are an entirely different discussion…