So, code quality is a complex topic worthy of all the good papers and books written about it. But what I have recorded here are some of what I feel are the more important and practical techniques I have employed over my career to help ensure that good quality code is delivered from developers. I have always wanted to delve into the metrics and theory behind code quality but honestly, throughout all the competing requirements, priorities and general chaos that happens in the IT world (and life), have never had the chance to really sit down and wrap my head around the whole affair. The techniques that I use rely more heavily on the soft-side of management. It puts trust in the people and experience in your development team and do not require much effort to understand and/or implement.
Why do so many of us struggle with code quality in IT? Well I think it It is so difficult to control and manage because of the most basic question which is so difficult to answer – What is quality software? There in the depth of this question lies the core of the issue. Then even after this question is adequately answered it is closely followed by the second question – How does one measure quality in software? Quality is hard to specify and measure at the best of times without applying it to such an abstract and complex concept such as code. For example, can you explain what makes a perfect knife? In the end quality is closely linked to fitness to purpose. A good quality bread knife has a completely different look than a good quality pairing knife. To encapsulate the exact specification relating to a perfect quality knife would likely result in a lengthy document for such a simple object. Try to extrapolate this to a complex software solution and the resulting set of documentation would be mind boggling and impractical (at least in most software projects). So we try as best we can to capture the quality requirements through use cases, test cases, QA cycles, UAT, load and system assurance testing (insert method/process here) etc. However, I have always found a rather large gap between a functioning system which is ensured by these techniques and processes, and what I would define as a good quality system. All of the more traditional software quality assurance techniques tend to focus on the end goal of the functionality of the system and not on the internal quality aspects of a system that are difficult to measure such as maitainability, flexibility etc. The conversation I was having was focused on not only how to ensure the more visible aspects of quality, but the internal and less visible aspects as well.
For me an excellent quality product means many things. First-most of course quality for me means a functionally working system when it hits the QA test cycle (not by the time the cycle has finished). It also means code that corresponds to a design that is coherent and understandable, simple yet flexible (yes I know these are paradoxical terms). It also must be modular and easy to maintain, have appropriate production logging and debugging information, plus a whole list of other requirements that I haven’t formulated in my mind well enough to be able to list but have build on from experience. I find an experienced developer can look at some code and comment if it is good, bad or simply indeferent as it relates to quality. But ask them for a list of rules that must be checked to ensure good quality software and this is an entirely different matter (a book in-fact). Developers who produce good quality code know how to produce quality code through experience. They have made the necessary mistakes required to learn. They understand the life cycle of software and have spent their time on the front-line (support). So we are (at least I am) requesting from developers good quality code, where I cannot accurate define and or measure what good quality code looks like…what a mess. So how do I help ensure these quality requirements are met on projects that I am working on. Put simply I rely on people and their experience.
Ensure there is Ownership
This is perhaps one of the more important aspects of ensuring good quality software. Make sure you have at least one person who is acting as the owner of the software. I’m not talking about a product manager here, I am talking about someone who looks at, and writes, the actual code. When there is no owner of the software you will find life is difficult in all aspects of development. There will be no consistent design, the resolution of issues will be difficult as no-one will be pro-active and take them up, an us vs them attitude may develop amongst the various aspects of the teams (normally development vs infrastructure) and finger pointing may become rampant as everyone tries to side-step the work. Having someone (or group of people) who take ownership and pride in code also goes along way to reducing the band-aid mentality when fixing issues and minimizes code rot.
A key to enabling ownership is making sure the software is structured in such a way that enables teams and people to own sections of code that have minimal coupling with other areas of the system. For more information on this check out on this check out Kirk’s post on modular designs.
Of course developing and creating this feeling of ownership is an entirely different topic (again many good books on this topic). My advice is ensure it exists, if there is no code owner this is something that needs to be addressed. There is likely a series of issues (most likely human issues) as to why there is no owner. My advice is to not ignore this and tackle the issue. Identify who the best owner should be, escalate the issue if there are no suitable people. Don’t try to continue development when everyone is just there to punch some code together, throw it over to the testers and then move on to the next task. The result will be poor quality code that eventually becomes a nightmare.
Code Reviews
In any good team you have a range of great experience across your people, my advice is use it! Code reviews are the perfect technique to leverage this experience.
When I first tried implementing code reviews as a development manager I went down the path of having a template which listed all the things to check for from code indenting and variable naming standards right up to design patterns to use. This did not work, people felt too restricted and not inclined to impart their experience into the process, it was in effect little more than a check list which in the end was not complete. My second attempt was to go to the other extreme and provide a template which was a blank table with two columns. The first the recommended change (free text) and the second the expected effort to make the change (small / medium / large). It was totally open and had much better results all round. I found critical issues were being identified by the process prior to release which was great. However, not only this was happening but the team dynamic was changing, people were learning from each other, talking, having more fun. I am also a big fan of code reviews because it one of those techniques that helps improve quality of the invisible aspects of software, conformance to design, standards, maintainability etc.
When starting with code reviews I struggled with when to ensure code reviews were completed. Are they done for only major sections of work or even for that one line bug fix? Personally I tend to let the code reviews drop off once we reach system test. I let bug fixes bypass the code review step unless there was a particular sensitive section of code being changed. This is where common sense and experience needs to step in to control the process.
The other thing to get right with code reviews is the pairing of individuals. Always try to have a domain expert involved or someone who you feel writes good quality code. Remember that owner we established above, if he is a good owner you will find it hard to stop him doing code reviews. The owner is usually heavily involved in code reviews but try to spread the responsibility around. There are many more benefits to code reviews than increased quality, knowledge sharing, coaching/training, increased communication. For complex or important sections of code don’t be afraid to do more than one code review. The way I look at it is that I am increasing the amount of experience going into a section of code by performing multiple code reviews.
One point of warning I will mention is that you still need to apply change management practice around the output from the code reviews. If a code review recommends a large change to be made to the system days before scheduled release then put it through the normal rigour and justification that you should impose on any change request. Make sure it is justified and necessary, investigate your options and choose the best one for the circumstances.
The Developer Demo
I introduced this technique to my repertoire when at one point I was constantly finding code was being released to test by a particular team where not even the simplest use case could be completed on the software. It was frustrating everyone and causing conflict across the teams. Requesting a demo to be performed from the developers suddenly changed all this. There was no more hiding behind the veil of email or instant messenger, there was the developer standing in front a host of people presenting the work they had just completed. Of course the phrases “That didn’t happen on my PC” and “that’s strange? (inclusive with a quizzical look on the developers face)” were still regularly heard in the demo’s but it dramatically improved the issue. Since then I have regularly used developer demo’s as a means to help ensure quality of delivery.
I usually employ them when a major body of work has been completed. I try to get each developer to present their own area and I keep the audience to a project team level (don’t go inviting the CIO to these developer demo’s!).
Developer demo’s also help instil ownership, a sense of teamwork, and tend to be good fun. Of course some developers will find the process quite confronting so try to coach them through the process. The actual demo is only half of the benefit so don’t be too concerned if it doesn’t go well, the developer knowing they will give the demo is the other half.
Action vs Consequence
There was an interesting place I worked while in Italy where when I started I was trying to come to terms with the development process. I asked the developers there what happens once the development was finished, who do we supply the software to? After some uncomfortable shifting around in their seats they told me they just put it in production. This shocked me somewhat as the company I was working for at the time was a global organisation and delivered services that enacted up to 8 million transactions per day. Now the reality was the nature of the service provided and the impact of issues was not great so the environment allowed such a development process (don’t get me wrong I still think it was risky and was never completely comfortable with the process), but the point I wanted to make here with respects to quality is what I found was that the developers produced very good quality code compared to other developers I had worked with in the past. I believe it was the close association between action and consequence that existed in this environment, the lack of the QA safety net that helped these developers produce such good quality code. If the developers did a release and introduced problems they would immediately take the flack for the issue and be expected to stay back and resolve the issue immediately (the advantage of a reduced process is you can get problems into production quickly but you can also get them out just as quick).
So my learning’s from this experience was to ensure the action vs consequence was felt within the team. If someone causes an issue make sure they are aware (no need to be nasty) and ask them to fix it (or at least help fix it). If you do not make someone aware of issues they are causing they will never improve. If someone is particularly bad you may need to take further action but try not to work around them and ignore the issues they are causing, it will destroy the team. One particular developer I worked with was constantly changing the framework and breaking other developers code (this was partly due to the lack of modularity in the app). He was actually a great developer and would produce loads of great code but just did not function well in the environment where the application did not offer good insulation to other areas of the application when he was making changes. He liked to work late nights and in the morning I would hear the cursing and complaints of other developers as their code had magically changed its behaviour overnight. I eventually had to segregate him to a separate application that was more modular and allowed greater insulation between himself and others.
So hope you liked this quick discussion of some of the techniques I have used to help ensure the quality of code delivered. Let me know your thoughts and please share any tips or techniques that you have used that have worked for you.
Cheers
Brendan
Eriah IT 