The Systems Sciences Institute at IBM has reported that the cost to fix a bug found during the implementation stage is approximately six times more expensive than one identified during design; the cost to fix an error found after product release is then four to five times as much as one uncovered during design, and up to 100 times more than one identified during the maintenance phase. In short, the cost of a bug increases exponentially as the software progresses along the SDLC.
Prevention is better than cure
The popular saying holds true in software development as it usually becomes harder to rectify an issue as the product approaches the end of the SDLC. If not handled correctly, bugs introduced during the design phase cost more to fix as they can have a severe impact and are more complex to resolve. Code changes for a bug fix can also affect the application’s functionality, requiring yet more counter-changes, adding to the cost, time and effort.
Take a banking application, for example, in which a security flaw is identified once the app has been released. For a product potentially used by thousands – if not more – the bug could cost a great deal of money to remediate. The effort, time and money required to resolve the issue is significantly higher than if the bug had been identified and fixed during the earlier stages of development. Not to mention, the complexity of deploying and implementing changes in a live production environment would further increase overall cost.
Bugs in the real world
One recent – and costly – example of identifying a bug after release is the exploding Samsung Galaxy Note 7 smartphones. This was the result of a suspected fault in the devices’ battery management system, which is supposed to monitor the electric current and stop the charging process once the battery is fully charged. A fault in this system could lead to batteries becoming overcharged, unstable and eventually exploding. This fault cost Samsung in the region of $17 billion following the recall of 2.5 million devices, and twice halted sales and production. Had this bug been discovered during the early phases of the SDLC, a lot of money – and Samsung’s reputation – would have been saved.
Building security in
Bugs are unavoidable, but improving security throughout the SDLC helps to create more reliable software. A traditional SDLC conducts security testing at the end, once the development team’s required functionalities are in place. However, security testing and risk factor consideration during the development phases will prevent bugs and errors at later stages. Some simple security testing practices can help with this:
- Identify issues during development with activities such as architecture risk analysis
- Review code using a tool or plugin which highlights issues and provides just-in-time notifications to allow developers to remediate issues
- Conduct a source code review – this could be as simple as having a colleague go through your code and suggest tweaks to improve performance
- Prior to software release, conduct penetration testing to identify any issues and make sure previously identified bugs are resolved
These simple practices help tie security into the software development process, ensuring issues are reduced and resolved along the SDLC.
