I am a web development team leader. One of the team members turns in code that is almost always bloated and inefficient, even though it technically works (although, from time to time it doesn't). I don't want to micromanage, but almost all of the work could be done in a much better way, and I'm concerned about future updates and other people working in his code having a hard time.
When Engineering Problems Become Project Management Problems
One of the team members turns in code that is almost always bloated and inefficient, even though it technically works (although, from time to time it doesn't).
This is only peripherally a project management issue. It is actually an engineering issue, but it bleeds into project management because your project process clearly has not made training, code reviews, retrospectives, or any type of continuous improvement process a priority or allocated any resources for it.
At the engineering level, these types of issues can be addressed through pair programming, test-driven development, continuous integration, pull-requests, and code reviews. It is up to each project team to determine what works best for them; that is outside the scope of project management.
What is in scope is the fact that process improvement only comes from two things:
- Resources (e.g. time and money).
Your project must commit to improved communications and apply sufficient resources to the problem if you actually wish to see measurable improvements.
Communication Through Feedback Processes
If you have not already instituted a code quality feedback process within your project, you need to do so. Without an effective mechanism for constructive feedback, any improvements (if any) will be ad hoc and unlikely to be part of the team culture. If code quality is important, then you have to make it an important part of the development process.
The specific details of the communication and feedback process are less important than the fact that the project has one. For example, Extreme Programming uses pair programming, while Scrum relies heavily on the Sprint Retrospective. Whatever your process, it should clearly define a mechanism for reviewing the team's internal development process, and provide a path for continuous improvement that is well-understood by the entire team.
Apply Necessary Resources
As for resources, quality improvement requires both time and resources. Resources can mean many things, but often mean:
- Allocations of budget for training and process improvement.
- Man-hours allocated to process improvement.
- Project overhead allocated to a continuous improvement process.
- Budget allocated for administrative or technical quality controls.
Of course, none of these resources will help unless the "tone at the top" encourages continuous improvement, and supports such improvement as more than an unfunded mandate. In addition, your project management process must make the cost of not doing these things visible as a form of technical debt.
Identify Sources of Technical Debt
If what you say about this programmer is true--we'll assume, a priori, that it is so--this is still more likely indicative of a process problem rather than an issue with a single individual. Specifically, if you have a programmer whose work results in slow, buggy, or broken code, or whose work is a drag on the team's productivity, you must be prepared to identify the process problem in play. For example:
- A company culture that fails to support continuous improvement.
- A company culture that rewards looking busy over delivering value or quality.
- A management team that fails to take responsibility for remedial training.
- A failure in the team's hiring or retention practices.
- A team culture that promotes individual contribution over collective code ownership.
- A team culture that fails to promote communication and knowledge sharing within the team.
There are no shortcuts here. It may be tempting to blame the engineer in question, and while this person is certainly a potential part of any quality problems you may be having, any actual blame rests with failures of organizational process and management (not team member) accountability.
You need to fix the real underlying process problems, and not just the symptoms. Otherwise, even if you toss this particular engineer overboard, there are no guarantees that his replacement will be any better, or that your process will not continue to accrue additional technical debt as the project continues.
A project with clear-cut process issues is extremely likely to have additional, less-obvious process problems, too. Without the proper project controls to continuously inspect and adapt, the project more likely to fail. Treat this obvious engineering problem as smoke, and look for the smoldering fire underneath before your project goes up in flames.
Implement a code review process on your project if you haven't already. You may even consider halting check-ins until a code review if complete to combat this issue.
If you have already instituted code reviews, then this is a place to provide constructive criticism on how the code could be improved. Attack the code, not the coder.
Leave room in your project for refactoring. Make sure not only you, but the entire team understands the value of refactoring.
This is a touchy issue and may cause conflict between you and the coder, so keep cool head. Code can be written in multiple ways to achieve an objective.
If the code is not written in a way you expected, but is clear and workable, then accept the code.
If the code is inefficient or has bug, then it must be pointed out CONSTRUCTIVELY to the coder for revision. Talk to the coder and convince him to avoid the technical debt.
If the code is written verbose but understandable, it can help maintenance later on. If it's spaghetti code, then there may need to be some coaching done.
Get a code review done by an architect if you have the availability, and see if everyone can make this more of a learning experience than anything else.
Also, if this is like a Junior dev doing the work, or an inexperienced dev, code reviews can only help the process more.