Share / SaveWhy Quality is your key to success
There are two common misconceptions about quality in the software industry:
The first one consists in thinking that following quality principles is too much bureaucracy and too expensive. According to this school of thought in order to do good SW quickly and cheap all that is needed is a team of good programmers. This misconception is the most dangerous because it often results in SW products that are buggy and late. Such a SW becomes a nightmare for the developers themselves because it is too hard to maintain. This situation is more common in small companies that don’t have SW development as their core business but have a small in-house SW development team.
The second misconception consists in thinking that quality principles are being followed just because a lot of testing is being done. This misconception is somewhat less dangerous than the first one because many bugs are found before the release time, but releasing on time is anyhow problematic and a lot of effort is spent in fixing bugs rather than adding new features.
Against these two misconceptions stands the true spirit of quality principles that consist in adopting a development process that minimizes the amount of bugs and problems in the project since the very beginning of the SW life-cycle. The reduced number of bugs will result in lower development costs, met deadlines, more satisfied customers and ultimately more business, profits and success.
This is the whole point of the quality approach: by reducing the possibilities for bugs to sneak into your SW you can save and earn more money by avoiding wasting time.
Think about the following:
1) How much time does your organization and your software team spend in fixing problems? Isn’t that time away from adding new features? Isn’t it wasted time and money?
2) How many problem reports do you get from your customers? Problem reports damage customer satisfaction and your company’s reputation. Unhappy customers reduce your future business opportunities.
3) How much damage is caused by a bug that is discovered shortly before the release deadline? What if it had been discovered earlier? Or if it had not been created at all?
4) What is the cost of a bug? A bug could cost a lot of man-hours for the fix, the company might loose a customer and in extreme cases somebody’s life might be at risk. You should avoid bugs as much as you can.
Certainly setting up and enforcing the right processes will require an initial investment. I call it an investment because in the beginning it will slow down the development activity, but if things are done correctly the return of investment will be a great reduction of the time wasted in fixing bugs.
Another interesting thing is the fact that the cost of fixing a bug grows exponentially with the time the bug lives inside your software. See for example the statistics in the table below: it shows that if a bug is introduced at the requirements stage but is fixed only after SW release, the fixing cost is 168 times higher than if it had been fixed immediately. For a bug introduced at coding stage the ratio is still 37 to 1. Amazing, isn’t it? Not to mention the customer satisfaction.
Table 1 Bug fixing cost escalation during the SW life-cycle [Source: NASA IV&V Facility]
| Development stage when the bug is Introduced | Development stage when the bug is fixed | |||||
| Requirements
|
Design | Coding | Testing | Integration |
Operations |
|
| Requirements
|
1 | 5 |
10 |
50 |
130 | 168 |
| Design | - | 1 |
2 |
10 |
26 |
74 |
| Coding | - | - |
1 | 5 |
13 |
37 |
| Testing | - | - | - | 1 |
3 |
7 |
| Integration | - | - |
- | - | 1 |
3 |
High quality is the result of a well controlled development process; a good development team will not save you from poor or missing processes. Think of a restaurant: no matter how good a cook you hire (=the SW development team), if the cook has to prepare a new dish (=the SW product) without a recipe (=processes), the preparation will take much longer and the final result is not guaranteed.
Certainly finding out how much process rigor is enough is a matter of trial and error, so don’t be afraid of trying and making mistakes or even asking for advice from others.
So how should you define your processes in order to prevent bugs? Well, there is no silver bullet nor one-size fits all recipe, but the following guidelines always stand well:
(a) Focus on user requirements: spend enough time discussing with the customers in order to get the requirements right (and write them down).
(b) Define efficient processes, follow the processes you have defined, periodically measure process results so that you can improve the processes based on the measurements and on the lessons learnt.
(c) Follow an incremental development approach with short period: this will (1) force you to test frequently so that you can avoid long-living bugs and (2) make it easy to accommodate requirement changes.
(d) Testing is vital: test early, test frequently, automate tests
(e) Testing alone is not enough quality: quality is the result of the processes followed by the whole team. Ensure that the whole team understands the importance of correctly applying processes to avoid introducing bugs.
In conclusion, quality is a key success factor for you as a developer, a tester, a manager or a customer. Be successful, demand quality just because you care about costs, schedules and your career.
Massimo Ferraguto
Director, Critical and
Real-Time Software
Space Systems Finland Ltd.
This article can be freely reproduced as long as the author and the link to the original source are included the reproduction.
