Estimation and the Inestimable

Share

I’ve just spent the day training some of my colleagues in ‘non-technical skills for consultants’, those skills that aren’t specific to any particular profession but which you need irrespective of whether you’re a lawyer, an engineer, a project manager, an IT consultant, an architect or any other kind of expert peddling his or her expertise.

What’s common to all professions is the requirement that you listen, ask good questions, structure facts and opinions well (thereby demonstrating your understanding of your client’s predicament), document them well, explain them and present them well, design solutions, make good judgements, persuade your clients of the merits of your judgements, implement your recommendations well, and so on.

There are a lot of skills on top of the technical ones.

(See The Art of Consulting – Some Golden Rules)

They’re not really skills that can be taught. My aim is to show how important they are and to provide examples of how they can be exercised well or badly. How do you teach good writing other than by providing examples of clarity, simplicity and brevity? How can you teach good design other than by pointing at something that’s well designed or badly designed? What I’m trying to instil through this training is an awareness that these skills matter and that complexity, redundancy, cliché, obscurity, and so on, should be avoided.

Judgement is the hardest topic. Consultants must assess what they’ve found out (facts, opinions, capabilities, priorities, and assumptions), and recommend a course of action in the (well-documented) circumstances. That is what they are paid well to do. It carries risk, and consultants are often wrong, something that consultants and clients must always be willing to admit and understand. But clients don’t engage consultants to tell them what they already know. They engage them to tell them what to do.

estimates

One kind of judgement in particular haunts businesses of my kind – estimation of effort required. We (LLP Group and systems@work) configure and implement business software packages. We’ve had more than two decades’ experience of understanding what our clients need and we’re good at designing pragmatic, value-for-money solutions. We’re even quite good at estimating how long it will take to configure and implement such solutions, as long as they don’t involve extensive software development.

But when it comes to software development itself our judgements are too often unreliable. Of course, we usually pay the penalty for that ourselves, because software development is very often contracted on a fixed price basis. Even after nearly forty years in the business of software development I still can’t understand why estimating how long things will take to develop is uniquely difficult. But it is, and not only for my company.

I remember the scorn I expressed nearly thirty years ago when I first came to ‘Eastern Europe’ and was told, ‘Well, how can I know how long it will take until I’ve finished it?’ when I asked for a software development estimate. I was used to asking the question and getting a number in reply.

But of course it was always the wrong number, and almost always a number lower than the number of hours, days, weeks or years a task would actually take.

The fact is that it is hard to predict the implications of change deep inside a software system without fully working it out in advance. And fully working it out in reality means actually doing the task. When it comes to the development of our own very sophisticated business software packages – time@work, expense@work and forms@work – it is the same. I have received estimates for years for enhancement work, and they’ve always been wrong. And I’ve long since given up the blame game. Things just have a habit of taking as long as they take. So now I ask whether it’s a big task, an intermediate task, or a small task and we fit as many of them into the available time as we can, assigning appropriate priorities so that we do the most important ones first. And we accept that our release dates must recede into the future.

What is the alternative? Does anyone have an algorithm for determining the impact of change on a system (all the places where one change implies another) or for measuring the complexity of change (which implies how likely it is that the team will do it correctly)?

Consultants must make judgements all the time, but sometimes they must accept that their judgements will never be as accurate as they would wish them to be., especially when it comes to estimates of the human effort involved. Some tasks are simply inestimable.

One of my colleagues recommended the Window Method. Look out of the window and think of a number.

Another recommended taking the average of multiple estimates. But in this case you would still have to double the number, at least.

Another recommended obtaining estimates, measuring actuals, discussing the variance and applying sanctions. But I know this doesn’t work.

Any other ideas?

If it can go wrong, it WILL go wrong

Share

You can never predict how customers will use computer systems, but one thing is certain, everything that can happen, will happen, whether you like it or not.

goingwrong.png

My company, systems@work, is the author of specialist software for expense management, and for the management of professional services organisations. Ours are highly configurable systems that can be used for a very wide variety of purposes. Even the terminology can be modified by the customer to suit the customer’s needs – one organisation’s ‘project’ is another’s ‘engagement’ or ‘case’, and yet another’s ‘investment fund’. Timesheets, attendance forms, expense forms, purchasing forms, absence request forms, planning, invoicing and reporting – these are some of the system’s possibilities, but each of our customers will set these up and use them in different ways. There is no right way to use our software, and however they set it up and use it, our customers must expect it to work.

Some years ago a few of our customers asked us to develop a new feature. Especially because end users might be scattered across the globe, they needed their administrators and first-line support staff to be able to log in ‘as if’ they are another end-user. And no, such end-users wouldn’t do any updates, they’d just be looking at the system as if through the eyes of the user they are trying to help, and yes, they wanted the end user to stay logged in whilst the administrator did his or her diagnosis, so both users could look at the same screen together.

So, we provided a highly restricted option called ‘Identity Switch’ that enables one end user, the administrator, we supposed, temporarily to log in as another.

Having two end users logged in to a system is uncomfortable. In our system, as in many, there are all sorts of temporary tables and sets of records that are identified by the end user’s name, and if two users are updating the same set at the same time you can create logical chaos. For that reason, we make it impossible for two users to login at the same time with the same user credentials. If they attempt it, the system says no.

Except, of course, for the administrator or support employee using the new Identity Switch function. We assume they will be careful, conscientious and that they understand the dangers of using Identity Switch to do updates in the system on behalf of the other user.

But you can never predict what users can do, and if there’s something you don’t want them to do you must prevent it, not merely advise them against it. Even if it’s more coding work up front, it will save you time later.

Over the last few months we’ve received a small flurry of reports of a few links between records getting lost.  It worried us, of course, and we spent many days investigating how it might have happened, finally discovering that it happened when Identity Switch was used. It turned out that Identity Switch was used for purposes way beyond those we had anticipated, not in exceptional circumstances, as we had recommended, but as part of the normal business process.

‘We warned you,’ we might say.

But what would be the point? We’ve still got to spend hours and hours diagnosing and repairing the problem.

There is no moral high ground to occupy if you’re a software developer. You can try to occupy it, but you’ll obtain no advantage. You simply cannot tell your users how your software ‘should’ be used, especially if you’re trumpeting its configurability. If it can go wrong, it will go wrong. If it can be ‘misused’ it will be.

In reality, there’s no such thing as ‘misuse’. If there’s something you don’t want your users to do, you must stop them doing it, not merely advise against it.

We’re working on it!

Just Three Days After Two Days to Go

Share

Yesterday we finally released Version 5 of time@work (expense@work and forms@work to follow shortly), just three days after we were only two days from completion. As I wrote on Monday, estimating and predicting in the area of software development is immensely difficult (Two Days to Go).

At systems@work we develop specialist software for professional services management, expense management and workflow. Our software is used all over the world.

PSWV5

Version 5 includes many improvements, though, inevitably, not as many as were on my list when we began our development work a year ago, and some improvements weren’t on my list at all. Priorities inevitably change from one month to another in response to the demands of customers and potential customers.

With every new release we must make advances on at least four ‘fronts’:

  • The ‘functional’ front. Every new release must be more capable than its predecessor.

We’ve made the calculation algorithm more powerful by enabling parallel sequences of calculations.

We’ve made it possible for invoices to be emailed directly to clients in Word, Excel or PDF format.

We’ve enabled drilldown ‘sub-reports’ from timesheets and forms.

And more.

  • The ‘technical’ front. Every new release must work with the latest operating systems, browsers, and devices.

We’ve added time capture to the capabilities of our App.

We’re shortly releasing an Android version of the App.

We’ve made some processes faster, such as invoicing and data import.

We’ve provided invoicing and data import capability in the browser. This means that end-users of time@work can now do everything in a browser:

Timesheets – submission and authorisation

Expenses – submission, authorisation and review

Forms – submission, authorisation and review

Approvals

Invoicing

Planning/Budgeting

Skills Matrix

Reporting

Data Import

Data Export

We’re therefore ever more ‘cloud’ ready.

We’re investing in ‘mobility’ by providing more options through our iPhone and Android Apps.

  • The ‘graphical’ front. We have to keep up to date with graphical fashion.

In this respect, we’ve still got some work to do. I have many faults, but one of them is certainly to think that in the end what matters most is what software DOES. I do believe that, and I probably don’t give enough weight to graphical considerations. But over the last months I’ve heard too many comments that our software is looking old fashioned, so over the next two months we’re going to modify the browser interface radically to bring it up to date.

  • The ‘usability’ front. We have to make our software ever easier to use.

We’ve made it possible to work with forms in ‘page’ mode as well as in ‘grid’ mode.

We’ve made it possible for end-users to import data into forms from Excel spreadsheets. This means that expenses, for example, can be entered into a spreadsheet offline and then uploaded.

We’ve added search capability and two-column lookups in the App.

But in this area , also, there is more to do. We’ll be looking at improvements in Planning and the provision of responsiveness in search tools so that searches are conducted as characters are typed.

I have a list of hundreds of suggestions from customers and colleagues, and I have lots of ideas of my own. Plenty of work to do!

Countdown – Two Days to Go

Share

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.

programmers

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?