A recent British Computer Society debate on software dependability claimed that the software industry “has many practitioners who are specifying software using ambiguous English and vague diagrams, implementing it using ill-defined programming languages with well-known and egregious weaknesses, and hoping against all logic and evidence that testing the resulting mess will somehow lead to a usable product.”

Several sensible suggestions were made to move away from this unacceptable position:

1. A lack of software dependability leads to considerable ‘downtime’. The first step is to understand and quantify the costs of this downtime. Only then will senior managers support measures to improve dependeability.
2. Software requirements are often inadequately specified leading to wrangling, rework and user acceptance issues further down the line. Just exactly how dependable the finished application should be is an important issue that is often neglected - also, is it more important to have an available system than a reliable system? More training for those specifying requirements will help. However, what is sometimes ignored is the responsibility of software developers to put their head above the parapet and highlight problems in requirements. This can be difficult if a lengthy requirements negotiation has already left the project behind schedule.
3. There seems to be a poor understanding of risk in the industry. Risk assessment is a specialist activity and so people should be given the right knowledge and should develop the skills necessary to perform such assessments. More emphasis should be placed on using the results of risk assessments to guide design activities.
4. The total cost of developing a software system sacross its life cycle should be considered when commissiong a system. However, there are a couple of problems here (a) Most organisations will have a poor or optimistic understanding of total life cycle costs (b) customers must take some responsibility here when purchasing software systems - if they continually choose software supplier based on loweest cost and do not consider whole life cycle cost then suppliers will price their bids accordingly.
5. Software should be usable. Again their is a corollary here in that developers and buyers should devote sufficient time and money to a project to allow a suitable level of usability to be developed. Raising the general awareness of usability issues among the developer community could also help. See my earlier post on the importance of usability in software applications for more information on what we’re doing in this area.
6. There was debate on whether individual developers should be certified or whether it was more appropriate to certify companies. I am a great believer in the responsibility of the individual for personal development but this can only go so far. Where a skill is required in order to perform a job the company has a duty to support the individual in acquiring that skill. Furthermore, individual developers are often just one small cog in a larger machine. If you look at the Standish Group’s CHAOS reports the top five key factors affecting project success are usually out of the control of individual developers: amount and level of user involvement, executive management support, clear requirements, proper planning, realistic expectations.

The discussion also raised several points which were somewhat ‘left field’ let’s say.

1. “industry needs to go back to programming basics, with everyone utilising one language throughout.”
2. The “movement to integrate software with the internet” is seen as a “worrying trend”. Rather than a fantastic opportunity.
3. “Secure systems should … perhaps not connect to the internet for safety reasons.” - Yes in some cases, no in others, depending on the application in question.
4. “Software designers have a habit of actually pushing customers into the direction they want them to go, leaving people feeling manipulated and ‘locked in’ to a process.” - Maybe some software sellers do this but I’m not aware of any software designers who do this. On the contrary most designers I have met are highly professional and value customer satisfaction as a key quality in their work.