The Pareto Principle states that 80% of your problems are derived from 20% of your causes. In other words, a small handful of factors decide the vast majority of outcomes. In software development projects, one particular factor costs teams massive amounts of time, money, and energy: bugs.
Many sources approximate that the average development project contains 15-50 bugs per 1,000 lines of code. Other experts such as Capers Jones estimate that organizations spend upwards of 50% of their development resources resolving these bugs. In their totality, the Department of Commerce estimates that software bugs cost the U.S. economy nearly $60 billion a year. It is paramount that these bugs are caught, and caught early, in the development process.
The Traditional Quality Approach
The conventional “quality path” to catch and repair bugs involves passing code from the developer to the Quality Assurance (QA) group and then to the User Acceptance Testing (UAT) group before being deployed into the production environment. QA focuses on correct functionality while UAT focuses on business requirements. Most organizations rely heavily on these groups to ensure quality.
QA and UAT groups, while incredibly valuable parts of development teams, are still steps removed from development. Code that fails an inspection in QA returns to the developer and then spends more time in a queue waiting to be re-inspected. If code fails in UAT, it spends even longer traveling back through development and QA before it is reviewed in UAT again. This waiting time is where bugs take their toll on a project.
The Source Quality Approach
Placing quality testing closer to the development team (or the “source”) helps avoid the costs from the traditional quality path. If a developer catches a bug, they can quickly remedy the problem without waiting on QA or UAT group members. Obviously, developers want to send code to QA without any bugs at all, but they do not bear the brunt of the responsibility for finding bugs in the traditional model. Using the Source Quality Approach helps developers publish higher-quality code while bypassing the lengthy, conventional quality path.
While there are several approaches to quality, the Source Quality Approach places greater responsibility for quality on developers than QA and UAT teams and involves two main components: automated testing and direct access to product/feature owners.
Developers can miss bugs in their code because they spend so much time looking at it from only one perspective. Having another set of eyes exposes more errors. This is the reason QA groups are so effective at identifying bugs. However, we can leverage testing features from integrated development environments (IDE) such as Visual Studio to be a second, faster set of digital eyes. This removes the need to wait on a QA group with a potentially lengthy backlog.
One example of the many automated testing tools comes from Visual Studio. Microsoft’s newest release of Visual Studio Enterprise (15.3) not only lets you automate unit tests, but also display the results of the testing in real time. Small icons to the side of the code tell developers immediately if their newest additions pass a unit test. This can catch the majority of the bugs that would traditionally clog the queue in QA.
Direct Access to Product or Feature Owner
Bugs concerning business requirements usually account for 30-40% of the total bugs in a project. In the traditional quality path, these bugs aren’t caught until UAT, the furthest (and most costly) point on the path. While careful planning during early meetings with business users can partially reduce this number, sometimes sudden changes in requirements or misunderstandings over features can’t be avoided.
Although developers and IDEs can’t catch these kinds of bugs, dedicated product or feature owners can. Providing developers direct access to a single business user (or other user traditionally assigned to the UAT team) gives a one-step process to check for requirement bugs. This process requires that the developer only wait for one business user to make a quick check rather than waiting for a piece of code to travel the entire length of the quality path to UAT.
Some Final Thoughts
The Source Quality Approach does not call for removing QA and UAT groups. These groups are important risk management tools that prevent bugs from sneaking into the production environment. Rather, the approach calls for the most bugs to be squashed at the cheapest point: the source. Ensuring quality early in the process saves time, money, and team member burnout while providing the business users with a high-quality product.
Have some thoughts, questions, or concerns about ensuring code quality at the source? Drop us a comment below.