Don't Fear the Programmer

Not to beat a dead horse, but Robert Cooper adds an important point to the enterprise development tool conversation...

And here is where it breaks down. All these unusable drag and drop tools, and “easy” XML programming languages aren’t targeted at programmers. They are targeted to suits who can buy into the idea that some non-techy is going to orchestrate these services and modify business rules. 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

I've not heard this lately, but in previous situations this point was widely held: BPM tools should be used to get the programmer out of the loop. I always enjoyed bringing testing into the conversation. The current crop of BPM tools I've seen up close are terrible at incremental development, testing, and release. And yet at least some IT shops have seen them as *the* way to get from under long software development cycles.

Those shops I know of also happen to be historically lacking good automated testing and release practices. Most of their causes for long development cycles have almost *nothing* to do with programmers, save for the fact that most programmers historically have not paid much attention to good testing either. Of course that's changed dramatically over the last five years or so.

Managers: if you have long development cycles, backlogs of feature requests and bugs, and "legacy code" that seems impenetrable, then please embrace your programmers' desires to be more productive and effective. There are many things you can do today to make big improvements. Buying tools that will reduce the need for programmers is a pipe dream for now.