“More Haste, Less Speed.”

Definition: The faster you try to do something, the more likely you are to make mistakes that make you take longer than it would had you planned it.

Our team recently completed two rather large projects with fairly short deadlines.*  Having overseen both projects beginning to end, it was easy to see the patterns of burnout and people feeling rushed.  Throughout the life of both projects, the questions, issues, and general quality of the product was fairly consistent.  Riiight up until the end.

In the last month and a half or so of each project, the quality of what was being produced really dropped and the number of bugs skyrocketed.*  Every story that I’d test would get kicked back multiple times, a lot of them getting kicked back immediately because the program would blow up as soon as I tried to test the feature.

Feeling a lot of pressure as a deadline approaches is natural.  Burning out after 6 straight months of 15-hour days and no vacation is natural.  It’s easy to just say “work at a sustainable pace,” but it’s hard when you are right down to the line and things keep coming.  The main thing is to try to recognize when you are feeling like that and when your code is unhealthy and attempt to mitigate it.  If everything you are writing is getting kicked back, try to find a solution to get your mind back into a productive state.  If you don’t, the end will be much more frustrating, as you will have to continually rewrite code and work on the same stories and rush to try to patch things to meet your deadline.

What can you do to get your mind back into a productive state?  Smoke a cigarette?  Go to Starbucks?  Sit in your car with some death metal blaring?  Change your socks?  Try to find something that works for you (everyone is different).  I’d love to hear some ideas/solutions in the comments.


*note: we are closing out the second one, it’s not actually done yet.  But you get the idea.

*note: the quality of the last half of the second project was markedly better than that of the first one, so kudos on team improvement!

4 comments so far

  1. G Valentino on

    There are a few things I do to get myself back to a normal state.

    The first is to change the music. I know it sounds petty and makes me ever-so-precious, but I find what I listen to will impact how productive vs easily distracted I am. It also depends on what I’m working on: I recalled last week that when I’m writing a help file “Birth of the Cool” is all that. If I’m in the middle of writing a really long user story Burial provides the right amount of ambiance. When I’m testing/accepting, The White Album does the trick.

    The second is the gym. Just today I was struggling with something and knew I had to get out of the office. I spent 30 minutes on the elliptical at a quick jog, listening to a sports podcast, and what I was working on became a little clearer. I wouldn’t say it solved everything, but I felt more focused about it when I got back to my desk.

    I think what it really comes down to is taking myself just a little outside of the moment. It might be something trivial like brushing crumbs off my desk, looking up a nagging question in Wikipedia, or even just taking out a pencil and paper and writing down the essence of the actual problem that I’m working on. I can’t take too long, because then I’ll completely lose focus, but just re-kajiggering my context (or even doing a simple thing that gives me a sense of having done SOMETHING) helps. It’s like the old motivational poster says: Obstacles are what you see when you take your eyes off the goal.

  2. Bill Sorensen on

    Borrowing words from Uncle Bob Martin: when you feel pressure, slow down.

    A deathmarch like this represents a serious management issue. The question isn’t “what can a developer do to mitigate the problem” but “what can management and the team do to avoid the problem.”

    Reduce scope. Institute postmortems. Look at Lean and Agile methodologies. If the developers are the only ones adding value to the project, why should management be kept on?

    • catschwamm on

      Unfortunately, while we are on a software team, we do not work for a software company: we work for a laboratory. Not everyone understands technical complexity and the way things should work, they just understand that if they give you a carte blanche budget and let you hire as many people as you want, the project should get done when they say it needs to be done. Regardless of how much we tried to reason with them/explain the situation (just because you hire someone doesn’t mean they can immediately jump into a project??), there were too many other pieces in the lab itself that were coming together at the same time and this piece is very necessary to make it all work. We have done everything we can within the team to get things moving at a reasonable, sustainable pace and we have successfully lobbied to get some deadlines pushed (while we were working on this Enormous Project we were expected to complete 9 more on the same date…we cut that down to 1, mostly due to the fact that we didn’t get the information we needed in time and/or things changed). However, “at the end of the day,” it’s still his company and we have to play by his rules.

  3. KevDog on

    John Wooden, legendary basketball coach for UCLA, said it best, “Be quick, but don’t hurry.”

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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

%d bloggers like this: