In the search for discipline


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:

  1. Give honest regular feedback to developers.
  2. Ensure novice developers do maintenance work at some point.
  3. Use technology and practices that make sense to developers.

One thought on “In the search for discipline

  1. Simo says:

    A. Threat of punishment.

    Take code review, for example. Here are four scenarios with varying incentives to conform to coding convention:
    1) Only one developer, and no code review.
    2) Three developers, which read each other’s code.
    3) 5 developers, everything is peer reviewed, coding convention is known to be one of the checklists in the peer review.
    4) Coding convention is a customer requirement.

    In scenarion 1) it’s all about self-discipline. In the other scenarios, the developer can expect
    to get insults if he neglects the conventions badly enough to make code hard to read or buggy.
    In 3) and 4), there is a threat of public embarrassment. In 4), the developer knows
    that he can’t get rid of the project before he has made it conform to convention.

    B. Organization size

    Big organizations have tendency to produce rules, processes and guidelines for pretty much everything. I’ll just link to Series60 coding convention (68 pages) to give you an idea of how far it can go. They easily swing to the other end of the discipline scale, and justify it by contrasting it to a situation where there isn’t any process.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s