I am an old dog when it comes to programming. I began nearly 35 years ago, coding in COBOL (an acronym for Common Business-Oriented Language), invented by Grace Hopper, who worked for the US Department of Defence in the 1960s. It’s a verbose language – lots of words to do only a little. Indeed, there really isn’t much that COBOL does to make your life as a programmer easier.

Of course, in ancient times, there were languages that were even closer to machine code, such as FORTRAN, but even with COBOL you still had to ‘lay out’ your use of memory and take care to prevent your variables from interfering with each other.

Over the years I’ve seen programming languages become more powerful. I wouldn’t say it’s made the job any easier. Whilst you no longer have to ‘lay out’ your use of memory, other complications have developed of another kind, as the possibilities and demands have multiplied.

Every few years or so, someone’s suggested a new ‘generation’ of programming environment where there’s more intelligence inbuilt into the language. But usually these ideas have disappointed. Either the language has to be so constrained as to be useless, or it simply doesn’t work. It’s either ‘you can have any colour as long as it’s black’ or ‘syntactical error at line 403’.

So, sceptic that I am, I was surprised to find myself responding enthusiastically to something a former colleague, Tamas, now living in Australia, showed me last week when I was in Sydney. He’s been taking some evening courses at the University of Erehwon in Sydney and he got drawn into a research project run by a Professor Kempinski. They’d heard about Tamas’s experience with business systems and were getting bored with the Professor’s obsessive experiments generating manufacturing systems for nylon stockings.  Tamas showed me how it works on his own PC and if it’s really what I think it is, then perhaps the programmer productivity revolution is finally about to happen.

I’m used to the idea of agile development. It’s a justifiably fashionable way of building systems, since it brings developers and consultants closer to the minds of those who will use the resulting system. The idea is that you involve real users in frequent prototyping sessions so that you can tease out what they ‘really’ mean when they say what they want, and they can see what you’ve ‘really’ understood when you show them what you’re building. But you still need consultants, and you still need programmers, so there are still the same two sides to the process – the users and the developers.

So, what if the users can simply ‘say’ what they need to a PC (or a Mac) without programmers or consultants present (and no Lilliputian programmers inside the computer).

The machine starts by asking you:

‘What system can I build for you today?’

You can’t exactly babble. There’s a kind of lexicon you must use. For example, you’ve got to say ‘location’ rather than ‘warehouse’ or ‘store’, and abide by many other similar rules.

So, I said, casting around for an application:

‘I need a system to manage the purchase, storage and sale of plastic bath mats.’

‘In how many locations can this bath mat be found?’ it came back at me, after only a very brief pause for ‘thought’. (One thing I should mention is that it only works if you adopt an accent somewhat like Professor Kempinski’s (Australian with a touch of Belorussian).)

‘Five locations,’ I answered. (I had to say ‘fife’ before it recognised the number, with a bit of a drawl on the ‘i’ to make it more Australian.)

‘Where exactly are these locations?’ it asked (the computer’s voice is modelled on that of Sheila, his wife, who is Australian, so actually there are risks of misunderstanding on both sides).

Once we’d got over locations, Sheila asked me how they might be assembled, what colour packaging they would come in (she rejected my suggestion of pink), who the suppliers are, whether they’re perishable (she obviously doesn’t ‘know’ what a bath mat is), what the pricing structure should be, and so on.

Finally we got to a very tricky area.

‘What do you imagine in the area of costing, mate?’ she asked.

‘I was thinking of actual costing, working out the true cost of products. Can you do that?’

‘True cost is an illusion, mate. There’s no such thing. Better use standard cost with monthly allocation of variances,’ she said. I have a strong feeling that Tamas was involved in this part of the algorithm.

After about an hour, I had a credible distribution system in front of me. In fact it looked like a system based on Microsoft NAV, but with more vibrant colours. Such systems usually involve months of programming work, not just an hour more or less alone with a PC.

I don’t know if the system would work in areas other than manufacturing or distribution (I see difficulties with simulation or planning), but it was an impressive demonstration, and for the first time ever I believe that we may not need programmers any more.

The software is still not ready. XI-Mera Version One will be launched exactly a year from now, on April 1st 2016. But when it comes, what will we do with our programmers?