Was going to send email this to a former colleague that shared some negative BPM tool experiences, but I think it raises some interesting points that are also applicable to RAD tools in general.

Frank Sommers uncovers some very interesting views in this post (both in posts it links to, and in the comments) on why many developers rail against BPM tools:

Java Community News - Are BPM Tools Useful to Developers?

Two schools of thought seem to be that developers don’t like BPM because of the threat (perceived or real) they pose to their livelihood (which I believe is true at least to some degree), or that they don’t like it because it actually gets in the way of doing things efficiently (which is my main complaint).

One of the good quotes in the article is this one from Robert Cooper:

“These products are unworkable because they are based on the idea that “You won’t need programmers anymore!” at least at a core level. Once you make that assumption you start building things that get in programmers way, and still include enough abstract programming concepts that no non-programmer is ever going to be able to work with it proficiently.”

Another good one is in a comment from James Watson, where he states “This idea that developers don’t want to use drag and drop tools because it’s boring is a load of crap… Most programmers are busy and if a tool can save them time and headaches they will use it”. He then goes on to list the typical cycle of how these things are introduced, which would be hysterically funny if it wasn’t so true. I have quoted the list here as there is no permalink to the comment:

1. The salespeople tell some suckers that they won’t need developers anymore. Many lies are told.
2. The company bites. They might even layoff some developers.
3. Non-developers try to create their own programs with ‘simple’ drag and drop tools.
4. Complete meltdown ensues when the first bump brings the house-of-cards crashing down.
5. The developers are now told to use this tool to do their work and maintain the steaming pile that has been built. (a.k.a throwing good money after bad.)
6. The developers try to maintain the mess that the non-developers wrote and create maintainable software without the tools that developers normally use (because they work.)
7. Productivity and/or quality continue to suffer. Developer morale drops. Much more ‘code’ is created than would be needed in conventional development approaches.
8. “Experts” in the tool are contracted and/or hired at great expense. They teach the developers how to work around all of the product’s deficiencies in order to be moderately productive.
9. The rising expenses cause managers to look for ways to reduce development staff. Outsourcing may be used.
10. A vendor comes in to tell some suckers that developers won’t be needed with their new drag and drop tool…