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
- 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.