Calm-Driven Development

Years ago, when I was young and crazy, the tail end of a long-term project would be rushed and hectic. A seemingly arbitrary deadline would approach, and despite (or because of) everyone putting in long hours, the remaining work would far exceed the amount of time left. Major features would still be in active development, QA would find serious bugs left and right, and there seemed to be no hope. (To be clear: the blame falls on me as much as anyone.)

This week, the team I’ve been working with for a year is wrapping up a large project. Over the last several weeks, everybody’s stress level has visibly lessened. The urgency of incoming tasks has lessened, the backlog is being evaluated for risk versus reward, but truly-important issues are rightly being called out and divided among the team.

Contrasting this year’s experience with older, troubled projects, here are the things that appear to account for the difference:

Sustainable Pace

Headspring sticks to a 40-hour work week, and everyone on the org chart takes that seriously. I’ve worked long hours in the past, and somewhere around hour 43 I start to produce poor work; really awful stuff which would inevitably spill into following weeks. Recharging at this pace is both easy and necessary.

If you’re facing death marches, it can often feel like it is out of your control. Both you and those setting deadlines may feel like putting in extra hours is the only ‘lever’ you can pull. Consider, though, where the deadline pressure is coming from. For instance, it may be that some vital core functionality needs to be in production to coincide with a marketing push, or to integrate with a third party’s own timetable. The death march pressure you experience might just be intended to alleviate fears that the vital parts will miss their due date. If you can then alleviate those fears through other, more sustainable means, death march pressure and long hours may stop feeling quite so necessary. These alternatives may include frequent demos of recent progress on vital features, frank discussions of feature and defect priorities, and raising issues as early as possible. When both sides are in on all this information, both sides have more levers to pull.

Consistent Estimation

This actually goes hand in hand with keeping a sustainable pace. When you are overworked and asked to give reliable estimates for 100 tasks spread out over the next 3 months, you’re tempted to take the number of workday hours in 3 months and divide that by 100. Surely it’ll be wrong, but you’ll make it all up on the weekend, right? By having to succeed while sticking to a 40 hour week, my estimates have gotten far more accurate, even when estimates are expected in terms of hours rather than some other measurement like relative complexity. Sometimes I’m a little over, sometimes I’m a little under, but once I was exposed to this particular project for a while, it became easier and easier to get extremely accurate with my estimates. My estimates now mean something that stakeholders can rely on, and the gentle pressure of sticking to 40 hours helped to retrain my brain.

Write. Down. Everything.

In past projects, my approach to note-taking was unorganized. On this project, I’ve gotten better about this, and it has paid off: I don’t waste time rediscovering information, from day to day and from month to month. See Memory Management for more on my new note-taking habits.

The End of the World/Project

I’m a little surprised to find that all the most-evident parts to our success don’t even get into technical concerns. Of course, technical details are always involved in a single day’s thousand little decisions, but when talking about the health of such a long project with so many contributors, human concerns dominate success.

The world may very well end with a bang today. Only the ancient Mayans and Neil deGrasse Tyson know for sure. This project, on the other hand, ends with not even a whimper. It’s not grand, and it’s not exciting. It’s downright boring, and that’s quite a step forward.