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

programming just isn’t that hard!

Programmers at times can take themselves, and their abilities, a little too seriously. The fact is that programming, in general, is just not that difficult. Sure, there are parts of it that are tricky but, at the risk of over generalising, the capabilities required by your run of the mill programmer are not that high. Are you sure I hear you say?

Well plucking figures right out the air I’d say that around 90% of applications involve a simple CRUD model. So what we are essentially doing is gathering data, processing data, and writing this data to the database. Two-thirds of this process is pretty simple, i.e. gathering the data and writing it to the database, this leaves the possibilities for hardness in the processing data phase.

Again in most situations the processing of data is pretty simple with no complex db manipulation or algorithmic mind games. Consider your typical web application for example. The processing of data is minimal, with little to no algorithmic work involved at all – I mean with Twitter there is literally nothing to do. Google on the other hand has lots to do: it has to make those search results shine. This is not to say that developing Twitter is simple, as the scaling issues will make your head hurt. However, scaling problems are only going to affect a very very small number of sites out there, but due to their ubiquity they are the ones we hear most about.

If all this programming nonsense is so easy then surely it’s difficult to make bad software?

Nope. The fact is that the only people who care what the code looks like are other developers. The code underneath could be shitter than an incredibly shitty shit and the end user wouldn’t know. As long as it carries out the task that they require the software to do, in a reasonably efficient and user friendly way, no one really cares. Oh apart from other developers.

Obviously nice structured code, that is easy to understand, free of bugs, and a maintenance dream is a good building block. However, it is by no means a guarantee that you are on to a winner. Marketing, user experience and coolness are all equally important, actually, they are probably much more important. I obviously can’t say for sure but I would imagine there are plenty of successful software products that are badly written but tick these boxes – maybe even most successful products, as they are free from the burden of the studious programmer.

So, essentially what I’m trying to say is that despite programming not being that difficult there are many other more important factors that contribute to the success of a software product. Many software products do their job, but the one that will be successful is the one that does it well.

All this is not to say that programming well is not important. On the contrary, it’s important to other developers who you work with and that is not to be underestimated. This is a topic for discussion another time though!

Finally, for those non-programmers out there, don’t start shouting “If it’s so simple why does it take so long”? Well just because something is easy it does mean there are not lots of easy things to do. I mean, hammering a nail into a piece of wood is pretty simple, right? But if I asked you to hammer 10 million nails into a bit of wood it would take you a long time. Remember this marketers and project managers.