3 Ideas For Defect Free Software, Yes It's Possible
Written on August 22nd , 2018 by Sabarish Muthumperumal
Nothing frustrates Software development managers and software development teams more than defects. It causes project delays, cost overruns and makes you and your team look immature and irresponsible in front of customers. Defect rates, defect density measures and defect reopen counts are the bane of many a development project. Few people can name even one piece of software which they use that has no bugs. A team member once argued that even software packages that have matured over decades such as MS Excel continue to have defects (ironically the team member was a tester)! However, over the years developing software and mentoring software development teams I have come to believe that it is possible to get defect free software, by following these 3 ideas –
Pride
- Awareness of the value that the software brings to the end-users transforms the developer mentality more than any other reward or penalty. It answers the question, “Who cares?!”. Enable teams to get feedback directly from users. Not only how their bad code is negatively impacting their work; but how the software is making their lives better. Developers should be encouraged to feel proud of their work.
- Encourage teams to aim for 100% defect free code. To aim for 100% defect free code; they need to begin to believe that 100% defect free code is not only essential, but is possible. Dissuade the common cop-out and aspersion that no software exists without bugs.
- Gamification – A weekly/daily Leaderboard of defect free code check-ins will drive home positive reinforcement. Reward performers with points, mementoes and “rolling trophies”. At one place we had soccer balls and footballs that got re-awarded (tossed around) on a monthly basis, with the autographs of the previous winners.
Process
- Inspect the right areas – “People respect what you inspect not what you expect”.
- Inspecting Defect closure counts will only encourage quicker turnaround in defect closure – Not code quality. Do not confuse expectations with inspections.
- Code reviews cannot and should not be an asynchronous activity. Feedback (positive and negative) must be given throughout the development process.
- Shower credits for building arks than for predicting rain
- Code Showcases over Code reviews – Provide opportunity for team members to show off their work – to their peers and seniors. Allow developers to explain the use case/user story and the code they wrote. This needs to be an all hands meeting (use projectors, video conferencing or remote meeting software), with active participation in an informal setting. The role of the leads/managers is to ensure that the mood and setting is encouraging and positive and not to be perceived as a witch-hunt. The collaboration serves multiple purposes
- Learning- Developers learn by examples of good code with live examples. Developers can get feedback on poor code/algorithms in an informal, non-threatening and friendly setting.
- Validation – Gives opportunity to validate that the developers have understood the problem and implemented a complete solution. Cross impact to other areas of the application become instantly visible.
- Code Refactor and Reuse – Seeing and learning about other areas of the application encourages discovery of reusable components.
- Automate Code Validation and Testing – Invest in and enforce the usage of static code analyzers and testing software to reduce the associated fatigue.
Perseverance
- Inspiration is Perishable – Resist attempts to go into auto-pilot mode too early. Establishing a process is great; but ensure that the process is implemented and followed through day after day, week after week, sprint after sprint and release after release. Show that as a manager you care. Attend each and every code show case session even of you do not understand much.
- Give time for the process to work. Changing behavior and mindsets are not overnight events. Resist attempts to switch processes or abandon processes when they don’t show immediate results. Frequent ad hoc changes to the plan and process not only confuses the developers and testers, but undermines your leadership direction – and makes you look weak and undecided.
What I’ve described are a combination of processes and tools that will help achieve better quality code. However, the key to success is the fundamental change in behavior. This can be achieved only through a conscious effort to instill and encourage better behavior across the entire team. Neither a top-down, nor a bottom-up approach will work – and the change has to permeate as a culture across the organization. Developers, testers and managers have to embrace the possibility of 100% defect free code to make it the new reality.
