Get certified - Transform your world of work today

Close

Reduce the Number of Code Defects by 50 Percent

Take the challenge!

22 December 2015


When looking back on my career and more than 20 years of software development, I can't help but think about how much the information technology sector has gone full circle, much like the fashion industry.

Technology in the early years included mainframes and client computers, which were followed by micro networks. Today we are back to cloud servers (mainframes) and client computers. Just like bell-bottom jeans, we have gone full circle.

It is time to go full circle with coding standards. There was a time when developers who were building massive applications with thousands and millions of lines of code without debuggers developed products almost completely free of defects. These were applications with less than 0.1 defects per one thousand lines of code in production. However, in today's world, some applications are lucky if they have only ten defects per one thousand lines of code. So what has happened? Are systems more complex? Are the applications doing anything different? What is the explanation?

Coding has become extremely bloated with multitiered architecture, but that isn't the root cause of these issues. The long and short of it all is that coding standards have substantially degraded over the past three decades. It isn't just coding standards, though. Business standards and business direction have decreased substantially due to leaders insulating themselves from the development team. This insulation or isolation directly affects lines of communication, which often results in missing requirements and countless miscommunications. What business people may not realize is that every time there is an added layer of communication, communication channels increase exponentially. This ultimately increases the chances of communication breaking down or communication slowing to a crawl.

So how do we fix it all? You can fix it by a two-pronged approach, which I have witnessed lower defects by more than 50 percent in numerous environments, while improving overall code quality. Best of all, it doesn't require additional staff, processes, or development costs.

1. Code-quality accountability. What is code-quality accountability? Developers must test their code no fewer than three times before delivering it to quality assurance.

How do you enforce code quality? Code signing is a good start. Second, use visible defect boards that upper management reviews each week. Strong code quality always circles back to strong code accountability.

2. Business accountability. What is business accountability? The Agile Manifesto states, "Business people and developers must work together daily throughout the project."

How does one enforce business accountability? It starts with business people working directly with developers to reduce miscommunications — miscommunications that exponentially increase with each layer of insulation. Business must come down from its "ivory tower" mentality and work directly with developers to convey clear, direct requirements and remove processes burdened with layer upon layer of bureaucracy and red tape.

Take the challenge, and see if this two-pronged approach, which uses development best practices, does not decrease your organization's defect issues exponentially.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 3.5 (4 ratings)

Comments

Robert Day, CSM, 12/31/2015 3:38:41 AM
Oh, how true. The last project I worked on had the requirements gathering done by a company who we no longer deal with and people in the software development team who left the company before I came on board. The business considered that the requirements gathering was a done deal before a single line of code was written. And there was no exposure to the heritage systems that the new application would have to interface with. When the system went live, we found all sorts of things that users did in the real world that we never anticipated (including some things that seemed counter-intuitive from a business standpoint!). Then the business came up with a list of things that they wanted that no-one had ever mentioned during the development process.

The result? A system that caused no little pain and needed a lot of rework, and that has taken nearly a year to have most of the problems addressed.

In our current project, however, there is a constant flow of communication between developers, analysts and the business; and the business has grasped that when we ask for guidance on how something works now and what would they like to see in the new application, we have a good reason for asking!
Hesham Amin, CSP,CSM, 1/16/2016 2:33:21 AM
I like both ideas but I believe there are more efficient ways to achieve them.
The rule of 3 tests is great, but what about impact on old code? Why not make it a thousand tests that cover both new and old functionality with test automation on multiple levels and TDD as a development approach?
BDD also promises better business collaboration with the team and a great way to achieve both automation and alignment.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe