Nothing is more aggravating on a software development project than quality issues. Developers build software that works locally, but when promoted to a testing or production environment, it breaks in embarrassing ways. 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 on 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 in combination.
Software craftspersonship is something we do not discuss often enough 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 career. 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 quality in software projects worldwide. Development organizations should encourage test-driven development, SOLID principles, design patterns, and code refactoring. These practices improve quality, and it increases speed to market with better quality.
The next cause of poor quality is the absence of continuous integration and deployment in organizations. Software requires plenty of supporting structures to operate. Configuration files store variables, configurable databases, and libraries help automate work. On one machine, it is easy to maintain, but changes can quickly get out of control with multiple developers. It is why having a source control took is a necessity. Next, an automated build system should be in place, so when code returns o source control, it is compiled and deployed to a testing environment. Finally, the same number of zeros and ones should move to other domains like 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 piece of code should generate a unit test and every defect discovered. Finally, developers need to treat quality assurance professionals with respect and like the first customer who views 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, put continuous integration and deployment in place, finally breed a quality culture in your organization. Otherwise, you have are doomed to live a life of aggravation.
Until next time.
No comments:
Post a Comment