From each of these technologies I have a book laying around on my bookshelf somewhere. For WF, I have bought Essential Windows Workflow Foundation about 1 year ago. Since then, I've read the introduction about 15 times. After reading the intro, I always put it back on the bookshelf again. Every time I did this, I asked myself the question whether I needed something this complex for solving such a simple problem. I mean, how hard is it to write a state machine in code that you need a designer to do it?
Some time ago, I was in a meeting discussing yet-another-self-developed-GUI-framework. During this meeting, the use of Windows Workflow was demonstrated for handling page flows. When showing this in Visual Studio, it literally blew up taking Visual Studio down with it. Then I realized for the final time, that a Windows Workflow or Biztalk solution is too complex for solving the simple problems it was designed to solve and just too simple for solving complex problems.
What is wrong with mouse-driven development you may ask? Besides the fact that it is not productive (ask JP about this), there is one major problem with using a graphical designer: it only serves the needs that its builders have incorporated. The moment you are in a situation that falls outside the main scenario's, you are out of luck. Add to this fact that graphical designers are typically very narrow in scope.
Now, I can prove this. At my current employer, I already rewrote two unmaintainable Biztalk applications that were written by drive-by architects. These Biztalk applications were very unstable. Developers and infrastructure people were literally terrified just looking at them. How on earth did I manage to refactor a complex Biztalk application with a flow that doesn't fit on 5 pages and that sends and receives messages from another component using remoting? Well, first I needed two weeks in order to figure out what the hell it was doing (so far for the documentation argument in favor of WF). Then, I wrote a console application in about 3 days with 200 lines of code. This console application had one single minor bug on the first week after it went into production (I did something wrong with a Mutex: just my stupid fault). No more problems and issues were reported until this very day. Simplicity prevailed and it felt sooooo good!
After reading Workflow software: I'm calling the bluff on Leon Bambrick's blog (a fantastic post I must say), I'm definitely pulling the YAGNI card on WF and Biztalk. I'll also be moving the WF and Biztalk books from my bookshelf to a box on my attic, hoping that I'll never need them throughout my further career. Whenever I see or feel the need for using WF or Biztalk, I'll immediately start looking for a much simpler solution.
