I played poker online last night. It was my first time in a long time. I played aggressively and was able to win quite a few big pots and steal some smaller ones. By the end of the session I had won a few dollars, but it could have been much more. My mistake was the usual one: I didn’t fold nearly often enough.
Poker is an art of discipline. Good players know when to fold. They avoid expensive mistakes.
Software development is an art of discipline too. As Scott Koon put it:
Every month a new programming language or methodology appears, followed by devotees singing its praises from every corner of the Internet. All promising increases in productivity and quality. But there is one quality that all successful developers possess. One trait that will make or break every project.
An undisciplined developer will not be able to ship on time and will not write code that is easy to maintain. A disciplined developer will not only enable the success of a project, but will raise the level of productivity in others. Software architects and developers do themselves a disservice when they attribute their success to whatever methodology they have adopted. It really boils down to how disciplined you are.
So how to become disciplined? How to bring discipline into your team?
Jeff Atwood suggests that new developers should be mentored by a discipline advocate. The advocate would keep reminding the developers about the value of discipline.
An excellent suggestion. But Jeff’s reference to Full Metal Jacket doesn’t make it sound very fun. Do we need to crack the developers to teach them discipline? Is discipline so unpleasant?
Think of poker. The best players do not dislike discipline. They love it, because they know it’s what separates them from losers.
Sometimes though you see a good poker player lose his discipline. Perhaps he just lost a lot of money to a worse but luckier player. He becomes frustrated and starts playing recklessly. Frustration feeds indiscipline.
In learning discipline, poker has an advantage over software development. There is a tight (albeit noisy) feedback loop between your actions and your performance. Players see again and again how playing loose costs them money.
The natural feedback in software is slower. It may take months for a problem to surface, and when it does, linking a symptom to the cause may be difficult. Worse yet, the original developers may have already moved to other projects, and miss the valuable experience.
One way to tighten the feedback is (as Jeff suggested) to give regular feedback to developers via code reviews and such. An obvious goal is to prod new developers to the right direction. But there’s another, perhaps even more important consequence.
Regular feedback gives a sense of meaning to developers’ work. Feedback-less coders lose motivation and become frustrated. And frustration feeds indiscipline.
The consequences of lack of discipline grow toward the end of the programs life cycle, maintenance. To learn the outcome of indiscipline, novice developers should maintain code at some early point of their careers. Since maintenance work tends to focus on the worst parts of the code, it can be hairy even on good projects. Most often maintainers make changes to undocumented spaghetti code, and hopefully learn a lesson.
Methodology matters. So does technology. Many parts of the development process can be automated. Doing them by hand can be very frustrating. Choosing a sensible technology allows you to focus your discipline on fewer parts of the process. The perceived friction of a wrong process causes frustration in the developers. Frustration feeds indiscipline.
To summarize, here’s my recipe to promoting discipline:
- Give honest regular feedback to developers.
- Ensure novice developers do maintenance work at some point.
- Use technology and practices that make sense to developers.