How can I explain to a coworker that he writes bad code? I just read a discussion of this question on a popular technical discussion site and I was disappointed by the answers. Most of the answers fell into three categories:
- Ignore it. It’s not your problem.
- Do something dishonest and manipulative, such as asking the coworker for technical advice when the real intent is to be the one giving the advice.
- Fire him, or try to get him fired.
While these may sometimes be the best available actions, it’s disappointing how many of the respondents are not aware of the tools Agile teams have for this situation. Before we get to that, let’s review the things everyone agrees on:
- Bad code is your problem. By the time I learned to program in the 1970s, it was already well established that the cost of maintaining software is far greater than the initial cost of writing it. This problem has only gotten worse as software has grown more complex. Bad code severely impacts the cost of change curve. It leads to an exponential total cost of ownership. The scary part is that the problem is initially invisible to the business. Businesses don’t realize how much technical debt they have until it’s too late to do anything about it.
- Object oriented tools and techniques have not solved the problem. While skilled developers in an optimal environment can use object oriented techniques to create code that’s easy to understand and adapt (i.e. flatten out the cost of change curve), this promise has been unfulfilled in most commercial development. Some argue that developer skills have actually decreased as more people with less intrinsic interest in programming have entered the field. Others point out that trading in our neckties (and pocket protectors) for blue jeans, and renaming our Personnel departments to “Human Resources” has not eradicated the management habits that harm product quality.
- Scrum has not solved the problem. I love Scrum as much as any other Scrum trainer, but we all know some of the world’s worst code is being written by people saying they’re “doing Scrum.” We’ve even heard it cited as a reason to write bad code.
What tools do a truly Agile team — doing Scrum the way we teach — have for this situation?
- Pair programming. When two people work together on the same code at the same time, there’s no way around discussing its quality and teaching each other alternative approaches.
- Test Driven Development (TDD). Writing automated tests and product code simultaneously can reduce the cost of change curve by enabling refactoring to occur with less fear of causing undetected regression failures.
- Merciless Refactoring. We clean up the code in small chunks (without changing its behavior) many times per day.
- Definition of Done. A good team agrees to a rigorous and clear definition of done, and does not demonstrate noncompliant work at the Sprint Review Meeting.
- Sustainable pace. At the Sprint Planning Meeting, the team accepts only the work it can do properly within the Sprint timebox.
- The Sprint Retrospective Meeting. Scrum requires team members to discuss issues with each other at the end of every Sprint. The “Kaizen mind” assumes we can always learn something new.
- Self management. Ultimately an Agile team should be involved in deciding who joins them in the first place, through an audition rather than conventional job interview.
To learn a more skillful way of doing Scrum, try one of our classes in a city near you. If you’re not ready to sign up for class, check out our free online Scrum Master training. For a general reference on Scrum, see The Scrum Reference Card. For information about the Scrum Master role, see An Example Scrum Master Checklist.