Countdown – Two Days to Go


Building software isn’t necessarily more difficult than building a building or a tunnel. You don’t get wet, or get mud on your boots. You don’t work with dangerous machinery or risk falling from a high place. You don’t need a hard hat to write software, you just need a chair, a warm place, a mug of tea and a computer.

building site

You would think that there are fewer unpredictable things in the logical space in which we software developers work (barring the malfunction of other pieces of software that form part of the system – equivalent, I suppose, to malfunctions in materials that form part of a building). It’s not an exploration of unknown conditions, either. You don’t unexpectedly discover that a logical turn takes you into more difficult ‘logical’ space, whereas the digging of a tunnel might take you into muds of different textures and load-bearing capability.

Assuming that requirements don’t change, there should be nothing unexpected when you’re programming, and nothing should get in your way.

So, why is it so difficult to finish software systems on time?

Perhaps the answer lies in the fact that whereas a building is conceived fully before construction starts – its outline, its height, its weight, and all its components and how they’re to be put together – the details of a software system are ‘worked out’ as it’s developed. A full description of it would be the system itself. Perhaps it’s like the development of a mathematical proof. The destination, the theorem, may be known in advance, but the tortuous path towards it has yet to be described. The full description is the solution.

We’re just two days away, we hope, from releasing a new version of time@work. We’re late, of course. We should have been two days away some weeks ago (perhaps months, if I’m really honest). But I’m not complaining. This is the way development goes. We’ve moved the goalposts a little, we’ve found some things more difficult than we’d expected. We’ve reversed out of wrong turnings when the ‘final’ version of a new feature wasn’t as easy to understand and use as we’d imagined. We’ve sometimes not anticipated that a change in one part of the system would cause logical problems in others. Who can eliminate such issues from the software development process?

It happens every time. Even after years, our estimates are sometimes wildly inaccurate. I hesitate to abandon estimation, since in software development you must choose between priorities, and knowing how long something will take and therefore how much it will cost is an important component of that judgement. I’m still not ready to shrug my shoulder and go down the route of ‘It will take as long as it takes.’

But it’s wonderful to be just two days away (or three, or four, perhaps) from Version 5. It’s been a year since we produced a major new release, and this one contains some exciting new features. I’ll list them when we get there in a few days time but for the moment we’re doing final assembly and a bit of cleaning up.

  • We need a revised demonstration database to issue with the new version. Not only must all the data be updated from 2014 to 2015, but changes have to be made to illustrate the new possibilities in the software.
  • We need to update the system help text with text from the new complete reference guide to the product.
  • We need to make some final graphical adjustments (consistent fonts, colours, styles, new login screens).
  • We need to fix some final bugs.
  • We need to  run a ‘release check’ across the entire product to test as many functions as possible in as many permutations as time allows (testing all of them would take longer than the lifetime of our solar system).

We do this with a series of iterations of the product. The problem is that this means we’re tilting at a moving target. I received a new iteration on Friday and worked on it over the weekend. Everything that wasn’t working before worked, but one thing that worked in the previous iteration didn’t work in this one.

Perhaps just one more iteration, today or tomorrow, and we’ll be ready to release on Wednesday. Fingers crossed.

Are programmers an endangered species? I saw an amazing thing in Australia.

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?