Quality goes in before the software goes out.

Nothing is more aggravating on a software development project than quality issues.  Developers build software that works locally, but it breaks in embarrassing ways when promoted to a testing or production environment.  Sometimes, new features break existing functionality.  It is a special kind of horror and misfortune.  People who use software expect it to work and do not wish to struggle with quality.  As someone who has attempted to deliver software for over twenty years, I recognize this frustration and have a few suggestions for dealing with quality issues. 

In my experience, quality issues have three root causes: insufficient software craftsperson skills, poor continuous integration and deployment, and a lack of quality culture in an organization.  Each of these is difficult to confront individually but can make a software project impossible. 

Software craftspersonship is something we should discuss more often in this business.  It separates the amateurs from the professionals in this business.  Craft is taking pride in your work and holding it up as an example for others.  Some people never develop that mindset comfortable to muddle through their careers.  It took me over ten years to build a sense of craft as a software developer.  I came to the software craft movement and continue to support it to improve the quality of software projects worldwide.  Development organizations should encourage test-driven development, SOLID principles, design patterns, and code refactoring.  These practices improve quality and increase speed to market with better quality. 

The next cause of poor quality is the need for continuous integration and deployment in organizations.  The software requires plenty of supporting structures to operate.  Configuration files store variables and configurable databases and libraries help automate work.  It is easy to maintain on one machine, but changes can quickly get out of control with multiple developers.  This is why having a source control tool is a necessity.  Next, an automated build system should be in place so that when code returns to source control, it is compiled and deployed to a testing environment.   Finally, the same number of zeros and ones should move to other domains, such as copying and pasting a document.  The development team should alter database settings, libraries, and configuration files, but the compiled code should never change.  Approaching software deployments like this will save you numerous sleepless nights.  

The last thing hurting your quality is the culture of your organization.  Developers should be restless when looking at code, looking for ways to make it easier to read, debug, and maintain.  Refactoring should be a regular part of a developer's job, and the organization should understand refactoring code allows for better quality.  Developers should respectfully inspect each other's code to help others improve.  Each new code should generate a unit test for every defect discovered.  Finally, developers must treat quality assurance professionals respectfully and like the first customer to view their software.  I believe this is the most laborious process in quality improvement, but you can move mountains with a healthy quality culture.  

Improving your organization's software quality is a matter of business survival because the release of buggy software undermines trust within your organization and, more importantly, with your customers.  Business partners will be more reluctant to purchase upgrades or use your automated systems because they do not trust them.  A few pennies more of software quality will save you pounds of frustration.  

Instill a sense of craft in your software development team, implement continuous integration and deployment, and finally, breed a quality culture in your organization. Otherwise, you are doomed to live a life of aggravation.  

Until next time.