Performance Issues – Poor Quality

Poor quality may not be immediately apparent to you unless you have established a relationship between the Quality Assurance team member testing the code and the programmer responsible for producing it. Quality plans and tools which put trouble tickets into a queue where they are managed by a team lead will tend to blur the lines of responsibility.

A low overall level of quality in the software being produced will have a negative impact on productivity and budget. Programmers aren’t producing new code when they are occupied in de-bugging old code. The portion of your project plan covering coding of the new software system should schedule a reasonable amount of time for de-bugging of code where the QA group finds issues. The definition of "reasonable” will depend on a variety of factors: the number and quality of tools your development team have at their disposal, the complexity of the system, the languages and systems being used to produce the code (programming language, web site platform, etc.), the QA issue reporting tools, etc. The amount of time required to address QA reported issues should be determined by weighing all these factors. Productivity will suffer and deadlines will be missed when this buffer is exceeded.

The symptoms described above will be evident when the quality problem is limited to one programmer, but on a smaller scale. In fact, if the team debugs one anothers code, the impact may be spread so thinly that it doesn’t cause the team to miss deadlines but may produce other symptoms, such as conflict within the team. One way of determining if and when you have this problem is to use your trouble reporting system to produce reports which show problems by programmer or system component. Look for a programmer or system component that are responsible for a disproportionate number of troubles. Your detective work isn’t over yet though. There may be valid reasons for the large number of defects the programmer is responsible for. The first factor to consider is the size and complexity of the component under review. If the component is much larger than the others, or much more complex, that may be the explanation for the large number of trouble tickets. One yardstick for measuring this will be the number of test cases that were executed for the component under review. If the failure rate per test case for the component under review doesn’t exceed your overall failure rate, you don’t have a performance problem with that programmer.

Now that you’ve determined you do have a quality issue with a programmer you need to determine the cause of the issue. Do you have the right development tools and techniques implemented to produce quality code? Do you have automated test tools to enable unit, thread, and function testing? Does your development team conduct design reviews? Do they conduct code reviews or walkthroughs? While a lack of proper development tools and techniques will tend to have a negative impact on all the code produced by the team, it will be especially negative for less experienced team members. Reviews and walkthroughs tend to apply the knowledge of the most experienced members on your team to drive improvements and correct errors. If your plan doesn’t provide these tools and techniques to your team and individual team members are left to their own devices to produce quality code, you should consider improving your development process before addressing performance issues.

Your development team has all the tools they need at their disposal and are using all the right techniques so you do have a performance problem. Now it’s time to address the problem with the programmer. Check the programmer’s design review and code review results. Have all the issues identified in the design review been addressed? Have all the issues identified in the code reviews been corrected? Are test results available from automated unit, function, and system tests? Is this programmer consistently responsible for breaking builds? Gather your evidence so that when you deal with your programmer, you can speak to facts not generalizations.

Schedule a one on one meeting with your programmer. The purpose of the meeting will be to determine a plan of action for improving the quality of the programmer’s code. Speak to the facts you’ve gathered and the impact the poor quality is having on project performance then let the programmer respond. They may make you aware of factors that have a negative impact on their ability to produce quality code which you were not aware of. For example, they may be working with languages or platforms which cannot be tested with the automated test tools at their disposal. If you determine the problem has a technical cause, the outcome of the meeting will be to investigate the correction of the cause, by acquiring appropriate tools, or other means. Do not accept a lack of time as a legitimate reason for poor quality. The lack of time may be legitimate but is probably caused by the inordinate amount of time your problem programmer is spending on fixing their bugs! Here’s a list of the remaining possible causes and some suggestions for corrective actions:

• The programmer doesn’t know how to use the testing tools, or doesn’t know how to use them properly.
• Provide formal training to the programmer on proper use of the tools
• Have an experienced programmer coach the inexperienced one on proper use of the tools
• The programmer is not correcting all the errors or incorporating all the suggestions produced in review sessions.
• Educate the programmer on the review process. Follow up this education by reviewing the audit sheets produced by the reviews and do not allow code to be promoted that has open audit points
• Moderate reviews of the programmer’s designs and code yourself. Ensure that the right programmers and analysts participate in the reviews.
• The programmer is taking short cuts – not posting designs for review, checking code into the library that hasn’t been reviewed, or not testing their code.
• Tell the programmer that this behavior will not be tolerated. Review the development process and identify the actions (e.g. post design documents for review, schedule code reviews, post test results, etc.) the programmer must take. Follow up this conversation by monitoring the programmer’s adherence to the process. Treat the problem as a discipline problem if there is no improvement.

The leeway your project has to investigate root causes for quality problems will be constrained by your deadlines. It’s always better to take corrective actions that will improve team members’ performance, but this may not be possible in all cases. You may be forced to replace the poor performer with someone who will perform. If you can’t effect this change on your own, escalate the issue to your sponsors and ask for their help to make the change. As always, make your case for the change by pointing out the risks of not making the change you suggest.

Almost all of the causes for poor performance presuppose the programmer wants to produce quality code. Your remedies will be different when this is not the case. If your project is burdened by someone who does not subscribe to your organization’s quality policies, don’t waste time trying to "sell” the policies to them, move them off your project as quickly as possible. Allowing this type of behavior to continue without taking action will have a devastating impact on team morale.

The information in this article is meant to compliment the best practices described in the PMBOK®. You should get your PMI certification, if you haven’t already done so. The three O website has information on how to get your PMP® certification and a PMP® Exam Preparation training tool (AceIt©) which will guarantee certification success. To find out more about certification, click this link.