The issue tracker is overflowing and the deadline is inexorably coming near: The milestone 4 build has to be reached! Feature-set B15 has to be fully implemented and needs to be QA approved but bugs still occur and some features haven’t even been worked on. Everything needs to be crunched in there somehow as bug fixing is not limited by the announced feature freeze… and so it happens that you go into overtime!
Because of actual events in my last weeks and months this topic just pops up again and again with me: Crunch and Overtime! Nowadays, these are even accepted as “normal” in not only Games but general IT and Development. I know only few other industries and departments that take crunch-time for granted… especially in the end of any project.
As soon as overtime happens it is already too late. As no project manager (should) plans with crunch-time something went wrong if it happens anyway. In some cases this is not necessarily bad. Most people do what they do, work at what they work because they like the challenge, they like the environment… they just like what they do.
But no matter how much you love your work, after 12, 18, 24 hours day after day after day no Red Bull nor a single good night sleep can help to keep you really focussed and up to the task that you are actually on.
I do not want to go into detail why something like overtime happens but there are some things professionally and socially that I observed over the last years and especially months I want to share if you have to crunch to release a feature in dependency with others!
Documentation vs. Communication (or “State the obvious”)
Pressure pushing down on me
Pressing down on you no man ask for
It may be so easy: You get your Game Design, your Technical Design, Interfaces, Standards etc. defined and start developing from top to bottom. In the end everything works out, interconnected and your task is finished. Great!
This real life“. In most cases many things have to be reworked or clarified and therefore communication socially and professionally is one of the most important factors when it comes to development in larger teams.
Nevertheless, especially after 12, 14 hours of work or during a night the receptivity starts to lack the focus it needs for intense communication and dialogues. People start starring at their displays trying to get around that one oddness or gaze into the coffee/energy drink creeping over the floor. People that normally question anything start developing “till the end” and not “to finish a task successfully” meaning they “crunch” all what is left into their current objective, finish it up as quickly as possible top to bottom based on the docs… and as clarification takes time if the design itself can also be interpreted in a specific implementation kind of way: It will be!
So, in the end of any project, after many hours of work, during nights etc. try and start being pro-active: If you crunch with others, state the obvious! If you do overtime yourself, start questioning the most simple things! This may sound annoying but is most important as the most well-formed process is nothing worth after four+ weeks of crunching. Normal things like “Did you add the graphics of that item?” or “Have you added the i18n key?” are the first things that get lost as soon as a narrowed mind is focussing on fixing a bug or finishing up a feature.
Crunch in Overtime (or “The right Task at the right Time”)
Insanity laughs under pressure we’re cracking
Can’t we give ourselves one more chance
Don’t get me wrong: Sometimes overtime can be very healthy for a project and team if e.g. a small group of people focus on one small feature-set altogether and try to reach a goal in a given time frame. Tasks get crunched, time just passes by and everybody is happy (with some pizza and beer of course this can be a wonderful achievement).
Nonetheless, very often overtime is used or has to be used to finish up tasks that are unfinished or even untouched. This leads to crunching in all the different tasks that just have to be done before a milestone or deadline is reached. So, the overtime is used to clear out the issue tracker and not to finish what the main goal was.
If overtime happens use it wisely and plan what to do! You are not in your right state of mind after hours and hours of coding, drawing, layouting, … and deprivation of sleep can lead to similar effects as alcohol e.g. headache or dizziness. The efficiency may seem increased after some energy drinks but based on experience and code review… it is not! You cannot state a number but if the efficiency and focus is decreased, plan in some laborious work, some monotonic tasks, clean up and work off method sets etc. Complete new structures, concept arts (depends on the crazy creativity ^^), calculations or templates especially interfacing with others (see above) are detrimental. Crunching has to be planned and should not just occur!
Social Competence (or “To Develop is Human”)
Watching some good friends
Screaming ‘Let me out’
During daytime everybody is calm, touched by the sun, always having a smile on their faces. But after 15 hours from dawn till dusk the smile starts to vanish from their faces as the sun sets.
It is no matter how “nice” somebody is during the day: during overtime and crunching tasks every mood starts to swing. If set under pressure over weeks, sleepless for days and crunching code into a machine people get nervous and tetchy.
Now it is important to be sensitive. Not only developers, artists, … in-between but also a managing director has to apply his best soft-skills and pressurize focussed but appreciative. Even ironic jokes that would cheer up anybody during daytime can break loose hell if people spend 20 hours working on one bug! This emotional intelligence is a major issue when it comes to delegated work. Nobody intentionally tries to not finish any task so do not sound like this.
To loosen up a little and see the crunching time as a task of the team. Do not take it too serious… it is more important to sometimes just take a walk and have a little water cooler talk. I am a non-smoker but if it is getting dark it can be helpful to just go with the crowd and to keep together. Share thoughts, introduce pair-programming (if not already given, 200% more effective during overtime in my opinion) and try to help each other as together the longest nights can become the best stories for the next day.
Stay Focussed (or “Utopia is nowhere near”)
It’s the terror of knowing
What this world is about
In 90% of cases overtime and crunch-time happens because a goal has to be reached in time. A milestone, a release build, … whatever. Unfortunately, during crunch-time it often occurs that some people see this time as “additional” hours to use (see above). They try to achieve 200% and not to reach bug-free 100%. Such ideas come from management/directors but also from developers that tend to pressurize themselves. If they do not get to see their bed for days at least this time has to pay out.
Always be realistic about what the goal is and try to not loose focus of what can be achieved during this overtime. As stated above crunching should be planned and therefore plan against the origin of that specific overtime. If people are under pressure it is more important to eliminate all mush and narrow down what you want to achieve. Overtime pays out in work and even for the person itself if something has been achieved. A e.g. developer that works all through the night coding and coding without having achieved what he wanted in the morning is only half the developer for the coming hours and days. But if you clearly achieve your realistic goal you are happy and produce endorphins. Your body is powered up and you can shed any sorrows of work. This is the best sleep you will have for months!
Keep the Balance (or “The equilibrium of Life and Work”)
And love dares you to care for
The people on the edge of the night
Overtime happens and crunching some work, too. This can be manageable to some degree. But if your whole purpose in life is work and you are crunching everyday, hour after hour, seeing sunlight only as a reflection of your display you will “dry up”.
As much as overtime has to be planned (see above), the balance of overtime, crunching and regeneration has to be maintained, too. Otherwise the productivity and benefit of the additional time decreases down to a (negative) point of no return… yes, negative. At least in many cases I have seen, people actually fixed and created productive resources and code up to a specific point where the amount of positives fell below the amount of negatives. And this just happened over one day. When days went by the amount of time that produced good quality decreases and got inferior to the amount of time producing crap. And the most important issue is: Those errors have to be cleaned up, too!
This is something general and may sound corny but to keep a good Work/Life balance is most important and overtime is no contradiction to it. But crunched overtime needs different compensation to be regenerated. As mentioned, a good night sleep might not be enough for a 80 hours week. Fresh air, sunlight, healthy drinks and food are a necessity to “survive” not only the crunch-time but the time after (downfall).
Post Mortem (or “The Lessons we Learned”)
This is our last dance
This is ourselves
Under pressure
This is not necessarily something to keep in mind during a crunch-phase but afterwards. Always recapture what happened! Always try to learn from the lessons made! A retrospective or post mortem should help to pinpoint problems, miscommunication, bad planning etc. for the coming tasks and have to be used for positive and directed criticism.
A review about every process, not only meta or technical processes but also socially can help to suffocate future errors. Especially critique is hard to deal with and often taken personal. But what directed criticism (a director that guides the review is most important. Reviewing, not discussing when it comes to focussed critique) should provide is what we require to grow, to evolve. Because that is what we all want: To become better! It may sound unfortunate but people outside ourself often provide a better view on us than we ever can.
Therefore, always have a retrospective, a review, a post mortem, a lessons learned meeting, … call it whatever you (or your project management philosophy) like, but do it!
So, if we have a look at the lessons we learned:
- State the obvious
- Plan your overtime
- Be social
- Be realistic
- Keep a Work/Life balance
and always recapture your work!
All this may sound general and soooo obvious but after weeks of overtime, pressure from the management and the deadline coming near it gets lost pretty easy.
Overtime happens and sometimes it can even be fun to see “this one feature being finished”, “this one bug being fixed”, especially in a nice social environment. Nevertheless, if you have to crunch keep in mind that not everybody is in the right state of mind and always remember some general work rules… maybe even pin them on a wall in front of you!
Also published on INsanityDesign.com