The Problem With Software

I was talking to a possible new Redshift Wireless staff member this morning, and we got talking about a project that he asked me to work on about 18 months back. He was explaining to me that the product was almost finished, and was what they needed, but I will get to that in a moment.

I guess the first thing that I should note is that I was asked to work on this project. At the time, I really needed the money, and I was asked what I needed.

I told them I needed a good specification

So, they worked on the specification. They had an idea of what they wanted, but I asked them to better document it. This took a few weeks from memory. When they came back to me, I did what I normally do when someone gives me their first draft spec.

I told them it was a good start, but they needed to do more work on it.

Well, I did not sit idly by when I got the spec, but really, they needed to get their ideas sorted. And without reading the spec, I knew a lot more was needed. Most people do not think about all the details that are needed in a piece of software, and I knew that in this project, the devil would be in the detail.

Once they were happy with their specification, I started looking at it in detail, deciding how I would actually implement it. To be honest, the specification was fairly good, and included an Excel Spreadsheet with a lot of the concepts described. They wanted this software out quickly, and I started on the database design. The problem was that after about a week of my time, over two weeks, I realized that this task was too much for me. The project, whilst well defined, had too many things to be worked out.

So, after a couple of weeks I needed to tell the client that I was unable to do this job for them. To say that they were disappointed was an understatement. I felt I had let them down, and I think they felt that I had let them down too.

Now, eighteen months later I finally found out where this project went next. Since I could not work on the project, they found another programmer, and apparently realized how much work was needed about four weeks later. Since then they have gone through numerous revisions of the specification, many more whiteboard sessions describing workflow and and a lot of money. They are just about finished, but it has been more expensive and taken much longer than expected.

So, what can be learned from this?

• Specifications always need more work. Always. These days, with my level of experience I can look at a spec and know if there is enough there. Most of the time I do not need to look, as most of the time, the specification is not detailed enough. Sometimes it is working out how long you can go telling a client to update their spec before they give up and start work anyway
• Software always takes longer than expected, and is always more complex than expected. Even when you take this into account!
• Programmers who need work who turn down work often know what they are talking about. If you see a programmer doing this, ask yourself why.

Here at Redshift Wireless, much of our business is involved with writing software. Experiences like those above should give you an idea of our philosophy. Basically do lots of planning before writing code.