in lists, Observations

the mark of sucessful software

Right, so I’ve been thinking about this for a while now. It’s a question that has been contemplated more times than anyone cares to remember, and still we have no good way of achieving the goal that it sets out. A quick search on Amazon will probably yield a thousand books on the subject – each and every one making you think the next is the holy grail. So am I going to tell you the question?? Well I suppose I must.

What is successful software? I’m sure the exact definition of this is subject to opinion and means different things to different people. Therefore all I can do is bore you with the details of what I think makes successful software:

  1. Software that the end user is happy with – a no brainer, if no one wants to buy or use it then you may as well give up. Happiness encompasses how the software looks, the user experience, and the functionality.
  2. Software that is finished to schedule – no one likes to wait, from management to clients, and even developers. Software that is late causes stress on everyone. Scheduling is hard and it has to be realistic. The end result of cramming and cutting corners is poor quality.
  3. Software of high quality – you can finish on time but if it doesn’t do what it needs to do in a manner the user expects, or simply is littered with bugs, then there is not much to be cheerful about. It has been documented ([1]) that bugs caught early can mean 1 hours spent now can save up to 3 to 10 hours later. As a result bugs caught after release cost between 40-50% more. This is always worth keeping in mind.
  4. Software that is cost effective – achieving all three things above but at a cost which prevents profit does not make sense. Costs are important and developers should also be mindful of this – even for internal software.
  5. The developers are happy and proud – I’m sure there are many employers that would be happy if they got software that satisfied the first four criteria but couldn’t give shit how their employees felt or what it took (out) of them. Stressed out employees are no good, they will only leave, and sooner rather than later you will find that you can no longer attract those employees that are smart and get things done. It’s surprising how easy it is to keep people happy without spending a lot of money.
  6. The management are happy and proud – if all the above is achieved at the expense of a stressed out, worn out, nerve shattered manager, then the same problems that arise with unhappy developers can be seen in management with the same negative results.

Now that we have a definition of successful software we can ask the natural question of how to achieve this. As I mentioned earlier, there are more books that I care to read telling me how to do this. Yet I feel none of them can apply in every situation. They all preach some methodology from the latest fad to the decidedly idiotic. If any one of these methodologies actually conclusively worked, there would not be as many books. I’m convinced that the truth lies somewhere in between them all and depends not only on the organisation, but on the people involved. So surely those involved in creating the software may have a better perspective on what will work than the author of a book? (This is not to say you can’t steal ideas that you have read and apply them in a suitable manner.)

I have my opinions on what I think would work for me, and is something that I can probably document in a follow up post. For the moment I will leave this with the statement that don’t be frightened to break rules and invent your own when something is not working. This is the only way we can make our software more successful.

[1] Rapid Development – Steve McConell

Write a Comment

Comment

 

  1. I agree that these are all valuable metrics in measuring the success or failure of a particular piece of software. Although I’m not sure I agree with the order in which you’ve ranked them, if of course that was your intention.

    This is how I’d order them:

    1. Software that is cost effective: No matter the quality or delivery time if doesn’t produce value for money then you might as well throw it away.

    2. Software that is finished to schedule: If clients require to be able to use your software to carry out a particular task on a specified day then in needs to be ready on time.

    3. Software of high quality: You could argue that this comes under the cost effective banner but that probably depends on your contract with the client. If your code is bad then it becomes more expensive to maintain and extend.

    4. Software that the end user is happy with: If people don’t like it then you won’t sell new versions or more versions or be given contracts new contracts. If they like it then they will tell others.

    5 – 6. I’d agree with this order.

    Chris

  2. Yo Chris. I’m actually unsure whether I was specifying them in order, subliminally or not! I was probably just running them in 1) the order I thought of them and 2) the order in which they flow into each other/overlap.

    Back to your point. I agree that cost should be number one but I think I would switch round your 2 and 3 – as I would accept a high quality product that ran a little late, but not vice-versa. As you point out though, one point can bleed into the other, which maybe eludes to the fact that it’s a combination of these things.