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.
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.