Observations on how to organise pairwise programming sessions to maximise output of quality code and minimise errors due to fatigue
As the day goes on, programming pairs become mentally tired until, by 4-5pm they are often damaging the code rather than improving it. It seems that good progress is made up to that point, but that progress can be undone by lack of concentration late in the day, and I see many teams spending the first 1-2 hours of the day fixing code they broke at the end of the previous day. There's a culture in business that people should look busy all the time ("heads-down-coding") and often people are shamed into working long after they have stopped being genuinely productive - hence the name "Quit while you're ahead". Frankly, most developers should seriously consider choosing a suitable point to stop and check their code in and then either do stuff that doesn't endanger the working codebase or just go home and have a life. Innovative agile or XP programming projects might like to consider this pattern when scheduling project coding work.
Conventional software development culture can have an ethos of long, intensive days of work for coders though this is not necessarily positively related to efficient production of quality code. XP/agile programming offers the opportunity to reconsider these working patterns and experiment with, e.g. Quit While You're Ahead. Of course, in many teams that simply wouldn't be acceptable - so it's a bit of a tough one to sell! The trick is for managers to allow developers to focus on clear goals and to turn a blind eye to such trivia as hours worked and looking busy. Also, developers must support each other and present a united front when defending their right to stop working when they've had enough.
To take advantage of this pattern, developers must make better use of their most productive time, which often is not the case. Teams tend to schedule meetings in the morning when they should be actually developing - and then the actual work itself gets pushed out to the end of the day (and beyond). It's also striking to note that I've worked in teams which experimented with a 6-hour day and the project velocity actually improved slightly. People have a tendency to fill up the time they think they have. If they plan on working until 6:30pm, then they often have less focus during the day and "faff about" a lot more. I see this especially in banking, where developers routinely work 10-12 hour days and yet simple projects seem to take forever to complete...
Text supplied by Jason Gorman