I’ve had this gut feeling about Windows Workflow (WW) for a while now. And, until now, I couldn’t think of the right words to say in order to explain it. Since I think I have a good way to verbalize it now, I thought I’d share.

I believe there is a problem in our industry where a great percentage of developers take a long time to understand simple, solid OOP principles and design patterns. Indeed, many developers never reach this level of understanding. My unsubstantiated concern is that tools like WW further shield developers from good design. The reason for this is that, absent WW, a developer could be shown how to write code using a state pattern, or chain of responsibility pattern, or a rules engine, or even simple OOP. Many developers simply don’t know how to implement polymorphism. My fear is that tools like WW provide an abstraction that hides, or inhibits, good design by simply providing a way for developers to click boxes on a canvas and write code in those boxes. What’s going on under the hood, or what should be going on under the hood, is lost to the developer.

Do tools, like Windows Workflow, inhibit development growth?

Disclaimer: I have not used WW. There may be great use cases for using it. My thoughts, above, are simply a gut feeling, and I'd be curious to know how others feel about the topic.

closed as not constructive by Robert Harvey, Jimmy Hoffa, Martijn Pieters, user40980, gnat Apr 18 '13 at 5:58

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • what is the question? what you wrote reads more as blog post – gnat Apr 17 '13 at 16:06
  • @gnat I thought the title made it clear. I'll put the title in the body as well. – Bob Horn Apr 17 '13 at 16:08
  • Have you looked into how well is Windows Workflow actually being adopted? Workflow was part of the .Net 3.0 framework so it has been around for a while and thus I'd ask if you've done any research to see if what you speculate is even starting to happen in terms of people using the tool? – JB King Apr 17 '13 at 16:11
  • 3
    Does IntelliSense inhibit developer growth? Maybe we should all be using text editors. You could write this a thousand different ways: Does [abstraction] inhibit developer growth? – Robert Harvey Apr 17 '13 at 16:11
  • 2
    To be honest, I don't get the sense that Workflow Foundation is widely adopted. So you might have given a bad example but I think I understand what you're saying. – Michael Brown Apr 17 '13 at 16:14

Windows Workflow is an abstraction, just like WPF, EF, Windows, and every programming language in existence. Like all good abstractions, it provides a way to leverage foundational concepts, building on the ideas created by others and improving on them.

Without abstractions, there would be no growth at all, and no civilization (as we know it).

Excellent software developers know how to take apart these abstractions and understand the underlying principles. The average ones just learn the abstractions and use them to build programs, and there is nothing wrong with that.

  • 1
    I think the point was, does this mean we have more bad programmers because they can "get away" with being bad? Its the old "you can't be good because you're a VB/PHP/etc programmer" all over again, only now its not so much language but framework that allows people to mask their lack of skill. – gbjbaanb Apr 17 '13 at 16:36
  • 1
    What skill is being masked, exactly? If you can build a workflow using WW in a fraction of the time that it takes to write your own state engine, doesn't everyone win? Would you require all programmers to learn assembly language first, just because they need to fully understand how their machine works? – Robert Harvey Apr 17 '13 at 16:39
  • @RobertHarvey That is exactly the point of my question. I'm not saying WW shouldn't be used. I'm wondering if it masks/inhibits skills for new developers. Sometimes these abstractions aren't the right tools for the job. When a developer starts to rely on it for solving most problems, I think learning is stunted. – Bob Horn Apr 17 '13 at 19:09
  • I was with you right up until "and there is nothing wrong with that." There's everything wrong with that. But +1 for the rest of the answer being spot-on. – Ross Patterson Apr 17 '13 at 21:51

I don't think a tool is what inhibits growth of a developer anymore than a specific tool can inhibit the growth of a carpenter (unless it's a poorly made tool). What inhibits growth is complacency. When I've gone through hiring processes, I've come across developers with years of experience with .NET and a number of successful projects but don't really know much beyond the basics of syntax and using the designer (and it happens with other mature platforms as well, it's just that there are soooooo many .NET developers, you run across this phenomenon more frequently).

I call it the M. Night Shyamalan/Tyler Perry syndrome. Success breeds complacency. Shyamalan had success with the "epic twist" gimmick and felt the need to make that a part of every movie rather than...learning how to write a better story. Tyler Perry has had a lot of success writing Moral Plays, now he has about 20 movies out that for the most part are essentially the same. A developer who has success using the basic tools (which is quite possible) runs the risk of becoming complacent and not pushing himself to learn more. You can have quite a successful career doing it.

The tools aren't to blame, lack of passion is.


I have worked a lot with tools of this general type ( not WW specifically but similar ) and my experience has been that they seem as though they will allow you to abstract away a bunch of functionality. That is their selling point.

There are many wheels in this world, there is no value for us as programmers inventing more of them. Why not abstract away some of those things not that we don't know how to do, but precisely that we have all done enough times that the prospect of doing it again is really unappealing. If we have a nice reliable tool that has been well tested by the vendor and ties into their operating system ( or is open source and well supported or whatever ) what reason could we have to justify not using it?

The practice has been, in my experience, that in many cases it would have been quicker to write it ourselves than to use the vendors tool and that for all the abstraction offered, you still end up needing to understand the internals of nine different libraries and the quirks of calling five different APIs and why they will work in this environment but won't work in that environment and actually maybe they aren't as well supported as they looked and it may just be the case that if we had written something ourselves for our specific situation it would probably have been quicker, performed better and saved us a whole bunch of headaches.

It doesn't always happen like that. But often, I'm sorry to say, it does.


There have been of course some examples in the past where newer technologies provided abstraction which made programming easier or for some cases even obsolete. I can think of

  • the invention of higher level programming languages (you did not need to learn assembler any more)

  • the invention of spreadsheets (allows users to solve a lot of problems without any programming)

  • SQL databases (a SQL query written in 20 minutes can replace a 1-developer-week program in pre-SQL technologies)

  • graphical UI designers

  • the wide adoption of programming languages with automatic memory management (instead of manual memory management)

And yes, each of that tools may have changed or reduced the need for certain development skills (for example, the need for assembler programmers). Thus, one could argue that they inhibit the growth of that skills. On the other hand, the also have increased the need for different, new skills - for example, SQL programming is a craft on its own.

For what I know about WW, however, there is absolutely no reason to believe this will have a similar influence like the examples above - the range of applications where this gives real benefits is IMHO just too small.


These tools and frameworks don't inhibit growth, they foster growth in different directions. There are many pieces required to build complex computational systems, some of those are core or common features like DB layers, UI frameworks, communication layers... Other pieces involve business or domain knowledge to implement the application functionality.

Some developers will work on those foundational pieces and their growth will be in those areas. Other developers will take these components and build them into a system, and their growth will in those larger view areas.

Not the answer you're looking for? Browse other questions tagged or ask your own question.