Image of Navigational Map linked to Home / Contents / Search Ramblings.DeveloperService

by Jim Karabatsos - GUI Computing
Image of Line Break

Software Development in the Real World

You know, I'm getting pretty frustrated at the perception that seems to prevail concerning the performance of our industry. Every time you talk to anyone who is not intimately involved in software development, you get the same old line - software is never built even close to on time or budget, that it never ends up being what you wanted in the first place, and that software people are arrogant and won't listen to what you really want.

The sad thing is that, for many years, I had accepted this "conventional wisdom" as the truth. In my twenty-odd years in the industry (some of them very odd years) I have been involved in a lot of projects and a good number of them did indeed take more time and money to develop than was initially estimated. I don't think that there has ever been a project that was built for more than one user group where all users got everything as they initially envisioned it. So it was perhaps understandable that I drew the erroneous conclusion that the software development industry was somehow unable to work within the accepted norms for efficiency and predictability.

But I was wrong.

Two things have happened in my life recently that have made me understand that the industry in which I work is no worse than any other and, in many ways, much better. Let me relate two simple stories and you will see what I mean.

The first incident involves a motor vehicle accident. One not-so-pleasant Sunday afternoon, I was stopped at an intersection waiting for the lights to change when the driver of a Range Rover decided that she would use my little Civic as a brake and ploughed into the back of my car. Luckily, nobody was seriously hurt (although coasting through an intersection against red lights when you are lying flat on your back on a collapsed seat is not something I would recommend to anyone). I called the Police on my mobile phone and waited - I was only a kilometre or so from the local police station so I figured they'd be right there. After all, I had told them that traffic was disrupted and we needed assistance to clear the road. Three hours later, after I had arranged for my wife to pick me up, a tow-truck to take the car and the insurance notified to expect it and after the husband of the other driver had also arrived and we had cleared the road ourselves, I was about to climb into my wife's car when the police finally arrived. Obviously, the accident was not that bad after all. Did I really want to fill in the report? It was going to be a lot of paperwork.

You know, there is a support contract in place between the community and the police force. We all pay taxes that are used to provide the infrastructure and staff to respond to these sorts of situations. We have the right to expect an appropriate level of response. I certainly felt that I did not receive that level of service and, as a basically 'average' citizen this is about the only contact with the police force I will ever have. Now, let me hasten to add, I am not trying to bash the police officers involved - I am sure that they were in fact busy and got to me as soon as they could - but the fact remains that I do not feel that I got the level of service I was entitled to.

A few days before the accident, I had received a message via e-mail from one of our customers. We had developed a system for them that has been in operation for about two years now. There is no support arrangement in place but we try to make sure they stay happy - that's just good business sense. Anyway, to cut a long story short, that was a very busy day for me so I did not respond to the e-mail until much later that day, from home after dinner. All I could do then was to acknowledge receipt and ask for more information because nobody from the client was still working at that time. When we finally sorted it out the next morning, the problem turned out to be simple - they had changed a printer on the machine but had not changed the printer driver to match. The total time that they were unable to print (from that one workstation only) was around 24 hours. You would not believe the negative feedback I received about that delay. It "just wasn't good enough" and they "expected more" from us. I guess we have just treated them too well in the past, responding within minutes. Let me also reiterate that there is no support contract in place nor have we in the past (or this time) charged them for this sort of running around. After all, this problem was not a bug in our software and in any case the software was well and truly out of acceptance testing.

Back to my car. The insurance company informed me that it would take two and a half weeks to repair it. Luckily for me, we had already arranged to go for a holiday with the family so that was not going to be a major problem. We would get back from the holiday on a Thursday and the car would be ready on the Friday. I made sure they had a note of the dates that I would be away and promptly put the matter out of my mind. Then the day came for us to go on holiday. Seeing as we were going to be away for two weeks, my wife had called the taxi company to arrange a taxi for us to get to the airport. She had enquired a full week earlier and had been told to book the day before, which she had done. In both conversations, she had noted that there would be five passengers (as we have three children). The taxi was booked for 10:00 am. When it had not arrived by 10:30, my wife called the company to find out what was going on. She was told that they were very busy and they were having trouble getting a six-seater to us. It should be no more than another hour. This was at ten in the morning on a Thursday, hardly peak hour for taxis. I ended up making an executive decision, packing everyone into my wife's Tarago and driving to the airport. Parking ended up costing a bit more than taxi fares would have, but I did get to the airport on time and my blood pressure stayed within acceptable limits.

While driving to the airport, I could not help drawing a parallel between this incident and the times when a software project fails to meet a drop-dead target. You know the sort of thing, the client "must" have this project finished by October 12 because there is a trade show they want to launch it at. Never mind that the project really needs an extra month - make it happen by the required date. What's that? You didn't finish all of it by the 12th? You software guys just aren't ever able to meet a deadline, are you? Gimme a break!

Just to wrap up the car story, when I returned from the holiday there was a message on my answering machine informing me that the car would not be ready on Friday but definitely on Monday. Needless to say, it wasn't actually ready until Tuesday. I took off from work an hour or so early to pick it up. When I got there, we went over the car with the assessor and I found a few little faults (like, the handle on the rear window was installed upside down - weird!). However, because of the fact the I needed the car urgently, I was prepared to just note the remaining faults and take it anyway - those faults could be fixed later. Unfortunately, when I tried to get into the car to drive it away, I found that the seat would not slide backwards on the runners and was jammed in the forward position. If you know me and you know the Civic, you just know that was never going to work. I also discovered that even light pressure against the seat back would cause it to collapse backwards because the seat mechanism had been damaged in the collision. I rejected the car and paid for a hire car for two more days while these faults were rectified.

So what happened? I had not put any schedule pressure on this project - they had quoted me two and a half weeks with no knowledge of my schedule or needs. They then delivered half a week late (20% over time budget) and with showstopper bugs still in the product, which took another two days to fix for a total slippage of about a full week or nearly 40%. I ask you again, is the software development industry so unique? What really made an impression on me, however, was that nobody made a song and dance about this. So what if it wasn't ready when they said it was? It was fixed now, wasn't it? The fact that I was out of pocket for the two days of car hire and my schedule was disrupted because I had to go twice to pick up the car did not rate a mention.

Lest you think this is an isolated incident, allow me to relate another story - the last one for this article, I promise. As our kids are growing up, we are finding our current home is a little small and are building a new one. We looked at the second-hand market, and decided that there were too many compromises using the old technology and opted for a brand new system - I mean, we looked at existing homes, decided they did not fit our needs and ordered a new home instead. Now we did not embark on the development of a custom solution, we decided on a shrink-wrap package - I mean, we did not design a home from scratch, we selected a design from the builder's range.

I'll stop that double-talk now, you can draw your own parallels. When we had finalised the plans and council permits, I asked for the estimated completion date. The builder told me that these homes usually take four months to build but that they would commit to a six-month completion date. I can understand that - they are saying that building a house is an inexact science and the margin for error is -0/+50% at the completion of detail design. Compare that to the way clients expect us to be within 10% at concept stage! By the time we are done with detail design, my estimates are good to within 20% and I've got to tell you there is no way that the estimation of software construction is any more precise than the estimation of house construction!

The actual start date for the project was January 6, which means that the scheduled completion date was July 6. As I write this in late October, we are still at least a month away from completion. Assuming that the house is indeed completed by the 6th of December (and I have my doubts) then we are looking at a schedule overrun of about 85% on top of a heavily padded (+50%) estimate! And this is for building a house! Let me hasten to add that the house has been specified from options in the builder's own range - we have gone for the Enterprise version, but there are no exotic materials, components or techniques in use anywhere. The only thing slightly out of the norm is that I have wired the whole house to CAT5 standards (as one does) but I bought a contractor in separately to do that work - would you trust a house builder with your network wiring?

Over the past few months, I have been trying to get a new completion date from the builder. I have been ignored. I have asked seven times for a meeting to review the project and to establish a new schedule. I have been ignored. The builder's attitude is that it will be ready when it is ready and the implication is that I am being a totally unreasonable user - err - client. And this is not a small-time one-man-band we are talking about. The builder is one of the largest in the country who claims to build one house per work-day hour!

Take some time and think about the products and services you use in your everyday life. Do they actually perform to any higher standard than you do in your professional career? I am beginning to think that the real problem is that software developers are both precisionists and perfectionists - they have to be in order to do the job. If a deadline is missed by even a day, that is considered a failure. If there is even one bug, that is considered a failure. So when we get any criticism at all from a client, we feel guilty and we admit to failure. This reinforces the behaviour in both the developers and the users, the former believing that they have failed yet again and the latter believing that this is another example of a software development failure.

So, take charge. Users are important but they are not always right. Make sure that you decide how long it is going to take to develop a given set of features - you can't just meet an arbitrary deadline unless you are allowed to trim the included feature set. Make sure you indicate the level of uncertainty and don't feel bad if you end up at the outer edge. Make sure you have enough detailed information before you commit to anything. Believe it or not, this is how the rest of the world operates. We have been conned into believing that we must perform better than any other industry. The builders would not even apply for the building permits from the council, much less start work, until we had chosen the colour of the paint for the whole house! This "let's start and we'll make it up as we go" attitude simply was not an option. So how come we are expected to commit to deadlines and start work immediately on the basis of a vague description of the problem domain?

Enough is enough!

Written by: Jim Karabatsos
October '98

Image of Arrow linked to Previous Article
Image of Line Break