3 AM days and ways to avoid them

Lately, a few of us have been burning the midnight oil to complete projects, and we find ourselves constantly leaving office at past 3 am.

I am a believer that every product-making person, should have their Zen moment, be it at 5 a.m, noon, or 2am. The Zen moment is when people are most productive, transitioning into a state of "flow".

Before we proceed, let me make it clear, that I am not opposed to people going home late, as long as they can find their Zen period. However, in the first half of this year, we've consistently found our collective Zen before 9-10pm, and hence been able to complete tasks in time for a good night's rest.

Let's analyze how we got into this 3 am state, and suggest areas of improvement:

Scenario: A demanding project required a lot of features to be built, within a very short amount of time. Imagine a complete backend and frontend consumer application, that comes with

• an optimized database
• application logic
• inexpensive
• easy to modify, in case of disaster recovery
• optimized front-end
• ajax-loading features with deep rules
• a CMS for administrators
• on top of it all, able to take stress loads of N Requests/Second, where N can be 5 to 10000.

As the design wasn't pinned down at the very beginning ( due to external forces ), we constantly find ourselves backtracking, and plugging holes in unclosed design loops. That amounted to a lot of time spent post-deployment. Developer's weren't building new features, but fixing bugs. On top of that, the project is what we call a "moving target", in which we get requests to change the design every day.

This extra time spend meant that new features couldn't be built in time, causing schedules to be pushed back. A classic scenario of an event chain gone inefficient.

How do we solve this? Here are the current constraints:

• limited manpower
• limited hours ( 8 - 12 hours/day)
• limited Zen periods ( we don't know when they turn up, or how long they last ). Zen periods are mostly required for building new features vs fixing bugs
• product must work on Minimum Viable Feature (MVF) approach : no bugs in functionality

How do we plan our work, so that we deliver within the constraints, and wrap up by 7pm?

Possible approaches to this problem:

• We could do sprint coding, where developers work in short bursts: 2 hour highly productive coding sessions to build the MVF. Avoid distractions such as small talk and watercooler chats. Take short breaks of 10 minutes each 2 hours.

• Solve easy bugs first, to improve developer confidence. Developers improve over time, the more they understand the system, and get comfortable with it.

• Have a mindset of ending the day at 7pm, and doing everything in their power in the first 80% of their day, solving the toughest coding problems first. Cruise in the last 20% of the day.

There are many more ways to approach this problem set. Drop me a line if you wish to discuss.