Discipline

The word "discipline" often is invoked to say that you should do more grunt work, jump through more bureaucratic hoops, and extend your hours. That isn't really necessarily the same as discipline in an agile sense.

Discipline in the agile sense is more like character, in that it consists in doing the things you know are right. What things are "right"? In this case, it is those things that align with the XP values of:

• Communication
• Simplicity
• Feedback
• Courage
• Respect

This card is an improvement of one that I kept handy in my last engagement. It inspired me to do make improvements where I could. When I made errors, it was there for me. Sometimes it was mocking me, because I momentarily failed to learn to what it was teaching. I guess you know a path is a good one when staying on it brings success, and straying from it brings failure.

Impose simplicity on all the software you touch, because code will naturally decay if not tended, and because it's often easier to invent a complex (or complicated) solution than to create a very, very simple model. Also because changes tend to cluster, so the code you change today is likely to be touched again tomorrow and next week. It is also possible that you may have to change it months from now when the current design foibles are no longer foremost in your mind.

Clean the code you touch. If you only make the smallest changes possible, it may seem like good risk management, but it equates to making interest-only payments on your technical debt. It's not a way to make a better next month. Instead, all the participants on the project should clean all of the code. Sometimes we avoid this, for fear that the code will be continually rewritten by different people. We consider that a good thing, if you replace "rewritten" with refactoring. We find that code moves from cleaner to cleaner forms as different people touch it. Each programmer should clean the code, and expect the others to clean it further.

Work on only one thing at a time because multitasking is a deal with the devil. If you split time among tasks, you do them all less well than if you could focus on one at a time. Because you have many things to do each day, you may want to work on the periodicity of your efforts to find a sweet spot. Some people recommend 48-minute work sprints, others may suggest 25-minute stretches. The thing they agree on is that focus on a single task means getting work done. Refuse the urge to multithread your head.

Work in exceedingly small steps. Michael Feathers describes programming as the art of doing one thing at a time. We learn through refactoring and Test-Driven Development to do only very small things between tests so that we only have one reason to fail: if one changes only one line of code at a time, and runs all tests after each change, then one knows exactly which line of code broke the tests. This applies to non-programming tasks too. One discrete, small step at a time can lead to more things being truly done sooner than ever before.

Shorten your feedback loops to the smallest period and the smallest number of participants possible. Do you need to have security review of code? Move the security reviewer closer to the coders. Perhaps embed them in the team. Perhaps bring them in as pair programming partners. Does the Customer take a long time to respond? Co-locate them with the team, demo changes as they are made, have the Customer run the iteration-end demo. Feedback loops are better if they are richer, faster, sooner.

Be transparent, especially in difficulty. This is where discipline gets sticky. The easiest thing to do when one is in trouble (or wrong) is to lie about it. This is also the worst thing that could happen. The point is to be transparent with those who can help you. A hidden problem is never addressed. If you are being assigned more work than you can complete, it's better to get the work flow reduced than to pretend you are going to "make it up" by working harder in the future. The whole "fail fast" value depends on being frightfully frank. Note that transparency in success is a pretty darned good idea, too.

Obviate and remove process steps because every process is inefficient to some degree. Note the word "obviate", because every moderately successful process produces some kind of (perceived) value at each step. If you can cease reliance on a given value, or gain equal-or-better value in other steps, then you can remove the the targeted step. For instance, you may have a long QC cycle following a coding sprint. If you can automate all tests for existing features then you may eliminate manual regression testing. If you can embed testers in the development team (shortening a feedback loop) then you can have them add to the automated test suite on-the-fly. It is possible then to eliminate the tail-end QC cycle. The same thinking applies to the process you are automating inside the program you are writing.

Go home before you break something. Or at least after reverting the first breakage that is due to lack of rest. Do not work yourself stupid. One might have to "power through a day" sometimes, but on those days one should not allow oneself to do anything important alone. And one should not push too hard to be the decision-maker of the pairing. One should listen to one's pair partner suggesting that one might need a coffee break or to leave early. Beware the urge to work scads of overtime in order to seem dedicated; be the one who works best, not the one who works longest. Don't expect to be 100% when you're on prescription antihistamines. Go recharge your batteries, and come prepared work all the harder when your brain is fresh tomorrow.