This is already the 4th posting on “What Drives Quality”, focusing on coding. Previous posting covered the factors that drive requirements quality and that drive architecture and design quality. Understanding what drives quality enables you to take action before problems actually occur, thus saving time and money.
With coding I mean activities to actually create the software product, using a programming environment or code generation, to write the code.
Some of the factors that drive Coding Quality are:
- Coding Environment – The quality of the coding environment (e.g., supported functionality, stability, performance).
- Root Cause Analysis – Capability to learn from defects found during development, (e.g., analyzing defects, determining common causes (related to processes, tools and development environment, capabilities, management & organization, etc), and defining actions to prevent them from recurring).
- Coding Capability – The skill and experience level of the design teams wrt coding, how to increase your craftsmanship
- Architecture & Design Performance – Result from the previous phase i.e. the usability and quality of the architecture and design for the development teams writing the code.
- Project Management Performance – Definition, planning, tracking and control of quality in the development projects and the delivered products.
- Process Management Performance – Defining and baselining the processes to be used for management and technical work. The support in operational usage of the processes for training, instructions, tools and templates and the availability of websites and experienced personnel.
- Design Base Quality – Quality of the legacy product used as a design base for developing the new product or product version.
- Coding Process Maturity – The quality of the defined and baselined coding processes, including all supporting materials such as training and templates. This includes, where appropriate, the usage of agile or other programming methods, such as user stories, pair programming, or patterns.
Coding Environment and Tools
Much has been written about coding environments, and about the effect that they have on productivity and quality. Programmers want to have good tools to be able to do their work. Tools should support collaboration, helping (distributed) teams to create and maintain code together. They should provide easy access to the code, and show it in such a way that programmers can quickly read and understand a piece of code.
Programming tools should automate what is useful to automate, but not more. I sometimes run across organization that define design and coding rules, and then automate these rules, for instance with automatic code checking in their version control system. Any piece of code that does not comply to the standards will be rejected at checking. While at first this may sound as a good way to ensure quality, it often is not. It is better to train and coach programmers to write good code, then to use a tool that bashes them. Most coding rules also have exceptions, a good programmer knows when to apply a rule, and when not. Finally, programmers will look for ways to pass the code checking system; and will find them, or will be allowed to bypass it in times of pressure. As the agile manifesto clearly states, “Individuals and interactions over processes and tools”, focus upon software craftsmanship will deliver better quality.
There are several ways to increase your coding capabilities. A recent book of Bob Martin, The Clean Coder, gives examples how programmers can exercise and sharpen their skills in coding dojo’s and doing kata’s. [vimeo http://vimeo.com/2499161]
Joining an open source project can be way to develop your skills, based upon the feedback received. There are several conferences where agile programmers can practice their skills. For example in the Benelux there are the xpdays. Also joining a community, like in the Netherlands AgileHolland or AgileOverheid can be a way to develop yourself, and build a professional network.
People over processes
Regarding item 6 on the list, Process Management Performance, I’ve deliberately used the term processes here though I know that lot’s of people are allergic to it. For me, a process is “the way we work around here”. It shouldn’t be a big document, the best processes are in the heads of people, and not in their cabinet. I consider a “Definition of Done” in Agile to be a process, it is the way that a team has agreed to work. If a team does a retrospective, and decides to do things differently in the future, for me that’s a process change. As indicated, the way that processes are managed affects the quality of products. Do people know the processes (know how they work together!), have they been trained to use them? Is there feedback from the actual usage, are processes updated and best practices shared? Do we know the performance of our processes? Effective support of processes is crucial to be able to deliver quality on time!
The quality of the design base, the legacy code, directly influences the quality of the products since this code is a part of it. Organizations that know how to manage their technical debt, and when and how to improve the quality of existing code, are more able to deliver high quality products. Reviews and Inspections can be a very effective way to continuously improve the quality of your design base, if applied in a sensible way, for instance within refactoring. Spikes are a great way to deal with risks in projects as early as possible. Automated testing can help to verify if the code is still ok after changes. More about how testing drives quality in a next article in this serie on “What Drives Quality”.
Understanding what drives quality enables you to take action before problems actually occur, thus saving time and money. Thing like the working environment and craftsmanship of your programmers have great effect on the quality of your software products. Test automation and continuous code quality improvement is vital to prevent quality issues with your customers.
(This blog was posted jul 5, 2011, and updated nov 3, 2011: Extended and Improved).