The first rule of Fouled-up-code* Club is you don’t talk about the
code.
The second rule of …
We don’t talk about the code, and so most of us are members of F’d-up-code Club. We’re not socializing the code enough. Shop upon shop I visit, I ask when the programmers discuss what’s in the code with each other. The usual answer? “Once in a while.”
If you’re not regularly talking about the code as a team, it’s getting worse. And “it” includes the time to understand the code, the time to fix the code, the pain the code causes you, the defect count, and ultimately the extent to which you have a real team.
We create standards but they idle and adherence falls off, and the code shows it, and attempts to get back on track fall short. We pair-program, but don’t switch pairs mid-story, and the solutions show it. (Yes, two heads produce a better-than-one solution, but a pair deep into understanding of their feature can easily produce a solution that makes little sense to others.) We hold tepid brown-bags that bore attendees and ultimately taper off in quantity. We hold retrospectives, sometimes, but the process crud dominates, and the audience isn’t usually right for talking about code problems. We sit in the same area (well, a small number of us do), but rarely call others over to our monitor to look at some cool or challenging code.
Try this (the opposite of the prior paragraph, duh):
-
Revisit your standard once a quarter at least, or simply when someone wants to visit a specific standard issue.
-
Pair program and take advantage of the two-heads effect. If you can’t pair, incorporate a streamlined inspection process. If you can pair, switch pairs at least once mid-feature. See if the third party can make sense of your tests and solution with minimal assistance from you.
-
Run end-of-day code sharing sessions on the LCD projector. Limit them to 15 minutes, and shoot for 5 minutes. “Hey, can we stop doing this in the code?” Or, “Here’s a new reusable construct that we should all be using.” Or, “Here’s an effective tool tip I learned.”
-
Find 60 minutes for a programmer-only retrospective each iteration. Make sure what comes out of them are commitments to improve that are actually met (otherwise don’t bother).
-
Don’t wait for the end of the day or a pair switch to discuss something important in the code. People should feel comfortable about standing up and finding an audience for a 5-minute ad hoc code discussion.
* More blunt folks can substitute other words for “fouled.”
