let x=x

“Programmerless programming” is a fad that never dies. It’s a mirage that never fades but always recedes to just out of reach.

Every few years a vendor, or a group of vendors comes out with some bright idea to allow some class of end-user, or business analyst, or what have you to build their own systems, in recent years usually by some type of graphic language (draw your system’s program flow right on the screen! bypass those pesky, and expensive, programmers who just ask confusing questions and force you to clarify your thinking!  press the magic ‘deployment’ button and your half-baked idea is in production in seconds!). In the past, these systems used “natural” language or “plain English”  languages such as say Director Lingo.  Every few years it moves onto some new paradigm or expression of the old one. And it always just ends up simply with a whole new class of programmers being created.

Do not trust any product – or standard – that promises to deliver “programmerless programming”. Plenty of 4GLs like SQL and the like are originally meant for non-programmers to use … imagine giving a business user just a SQLPLUS prompt now! Included in that mix there was CASE … a recent example from the past few years I can think of might be BPEL and ESB style tools, or for another example a number of attempts to define architectural languages that generate the system components for you off the UML or similar.

A big issue I see with these systems is that they tend to be highly resistant to modern programming principles and practices. For example, test-driven design – or even simple unit testing. Sure, if you’re building a web app with these things, maybe you could use a web-testing framework to build functional tests and build-to-pass. But most of these tools are very resistant to a test-first approach.

Take Oracle’s BPEL tooling. For a start, you’re forced to used JDeveloper, which is a crap IDE you’d never otherwise inflict on yourself (it is so bad, on start up it displays the most meaningless product slogan I’ve seen seen on such a tool – “Productivity through Choice”). But more than poor tooling, the very paradigm is completely broken. Forget about a test-first approach (although I’m sure there’s some seriously weird way to achieve it), just try setting the damn tools to have the traditional development, testing and production environments. When ever you need to call a service end-point, you are bound to the particular host and port you specify – it’s embedded in XML document that represents the BPEL design. The workarounds? Well if you are super organised you could arrange for your different environments to contain identical setups and  use DNS hacks (or host files) to ensure that each service looks the same when you move from development to integration testing to production. Or you can write Ant scripts (or sed and awk if you really want) to search-and-replace the offending hostnames and ports and replace them with the correct values for the target environment. Clearly, once you use it, you see that the tool’s paradigm is, in reality, to just hook up the IDE to the production server, draw your pretty flow chart modelling your business process, then publish it straight back into production. In other words, there’s a whole new class of programmer out there now – BPEL programmers – and life must be a nightmare for them. Its fundamental paradigm is broken. Given me any language with a unit test framework with a half-decent programmer on any day of the week, and you will beat the pants off this system in productivity and choice. It’s living a lie – and a big one.

Ultimately, as each new generation of “programmerless” program-construction tooling comes along, it allows developers to do more powerful things (and sometimes, less powerful things in a more retarded way). And the scale of the task always increases to the point where development specialists are still needed. In my view, there is a definite on-going role for for the talented programmer/analyst who knows how to take a vaguely-worded, incomplete, and contradictory bunch of requirements expressed in common verbal language and then ask the right questions in order to clarify them and decompose the requirements to a series of simple logical components – and then develop and deliver those components in the form of usable systems. You need to continuously learn new languages and systems, but the basic skills stay the same.

Be Sociable, Share!

•