Focus on Fundamentals: Reducing Defects in Software Development
Author’s note: The Focus on Fundamentals blog series addresses the challenges that limit applications solution delivery success.
I once worked on a project delivering software to be used by air traffic controllers. When we found defects in the software during a code walkthrough or during system testing, we joked that we were never going to fly again. However, on that project we were using disciplined software engineering processes and were very proud of the quality of the software we were developing.
The sad reality is that much of the software being developed today is very buggy. I suspect part of the problem is that software developers enjoy writing code and the ‘high’ they experience when they see their software become reality (such as an applet downloaded by thousands of users or as part of a web-based application used to drive a company’s key business process).
Why is this a problem? It’s because most software developers focus on getting their code into production as quickly as possible. They know how to write algorithms and how to use the semantic constructs of their favourite coding language. However, they usually don’t give much thought to the process by which they write their code—they do not know how to engineer software. Developers generally apply the following process to developing software:
They design the basic logic flow and then start coding as quickly as possible. Typically the code/compile cycle is used as a means of ‘testing’ their unit. If developers prepare a Unit Test Plan, it is often done as a formality to meet project documentation requirements after they believe that their module is working.
The Software Engineering Institute (SEI), at Carnegie Mellon University, has shown through extensive studies of projects and analysis of metrics that this typical approach to software development is dysfunctional. It leaves a large number of defects in code to be discovered later by System Testing.
To properly engineer software modules, developers should spend more time thinking through their module design details, not just the basic logic flow, as illustrated here:
They should then participate in a peer review of their module design—a critical step that is often skipped. Developers should then prepare a Unit Test Plan (UTP) before writing a single line of code. By creating the UTP before writing code, developers effectively test their design. After the module is coded, the code should then be subjected to a peer review. Peer reviews can remove far more defects from designs/code than a developer will find working alone.
None of this is new. Each step has been around for decades. However, the order of the steps is significantly different than typically applied. We can produce much higher quality software if we follow this software engineering process.
Coming soon: Focus on Fundamentals: Scope is Everything
Related links:
- HP Applications Transformation Solutions (website)
About the Author
Jim has been with HP for 33 years and currently leads a global Strategic Capabilities Management team, with a specific focus on Business Analysis and Configuration Management. Jim also manages a team within the US State, Local, and Education division of HP. He was a member of the IIBA committee that created a Business Analyst Competency Model and he participated in the development of IEEE standards. Jim graduated from Harvard University, the University of British Columbia, and Ottawa Theological Hall. He currently lives in Toronto, Canada
