Do tools, like Windows Workflow, inhibit development growth? [closed]

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.