Every time I’ve heard about crunch, I hear how it should be avoided and it’s the worst thing in the games industry. But when you talk about the individual elements of crunch with piers, friends, colleagues, and people in the industry… It’s described as “normal”. overtime, impossible timeframes, taking shortcuts etc.
Being a professional means avoiding these “normal” things by being… professional. It’s proven over and over and over and over again how these “normal” things are short sighted. No matter how you shape it, long term crunch sabotages the future of the product and ability of a team. I want to highlight long term crunch because short term isn’t as bad. Personally, I’d avoid anything more than a week because I know my limits. You should know yours.
Spotting crunch early
How many of us go above and beyond the call of duty? For many of us, it’s instinctive to be helpful and want to be useful. But when we’ve got too much on, there’s not enough of our selflessness left to be selfless, and what I’ve noticed is that when you get to this point, an incentive is usually introduced. The incentive could be a promised promotion, time off, bonuses, the chance of working somewhere or on something special etc. Once that incentive is in place, it almost becomes instinctive to meet the new requirements no matter how impossible they seem. Realising this early, and countering it is important for a professional. And this is not what I have been for the last six months.
You should know when you have too much on. It is essential to knowing how much you and your team can manage, and therefor how much will get done on time.
I did a lot of research after my most recent crunch as it was a particularly cruel one. There’s a bunch of change I’ve implemented in my discipline and team that I can handle personally. My team is very junior. I, as the leader of the team have a little over a year in industry and very limited time with any senior programmer. I cannot tell you just how much I miss being pointed in a direction and running with it by someone more experienced than myself. My UK programming team consists of a myself, a junior and an intern. So how can I get us better as a team? Peer working is a practice I’ve started to advocate for. The idea is to spread the conceptual load of each project’s features. The number of times I get distracted a day is infuriating because any problem I’m working on can take three or four times as long as it should, simply due to having to re-contextualise problems repeatedly. Having two people tackle a problem leads to better practice on a whole. Distractions (requests, help, meetings) can suddenly be handled by half of the duo working on the problem at hand. Then when the duo is back together, re-contextualising the problem is much faster, or perhaps the partner is coming back to the problem finding it already progressed. But there’s more benefits to peer work; sharing of good practice and patterns, constant rubber ducking, a broader set of knowledge in general, seeing how each other solves problems and of course, two heads are always better than one. I work with our junior regularly and they fail to see the value of their input. The number of times I’ve gone down a rabbit hole they’ve pulled me out of just by a small suggestion is invaluable. Maybe I’ll get into mentorships of juniors in a future post.
Anyway, the more difficult challenges to manage as a leader are the external factors that affect a projects end goal and vision. Feature creep is a big one, unperceived problems, changes in requirements etc. Reflecting on the most recent chaos has given a bit of insight into a few key areas that I’ll watch out for in the future.
Overtime
Commitment
Hope
Overtime is an interesting one. It’s different for everyone and some disciplines handle overtime better than others. I’ll focus specifically on software engineering and the systems engineers; the guys who put together the system that enables gameplay programming and for the implementation of content. In small doses with a fresh team, overtime is worth it for a short-term goal, but I’ve noticed that you must be prepared to let the team rest afterwards and the team cannot be allowed to take shortcuts or break discipline. Taking shortcuts shoots holes in the future of the product and the little time gained will cost double after the intense sprint because the team will need rest, and the work will very likely need to be redone. Two weeks taking shortcuts for my team cost over two weeks to amend because of this reason. The break that the team earns will be most beneficial if it is immediately after the crunch, and equal to the number of days working overtime. I would consider anything over a week with systems and software engineers to be detrimental as the feature implantation of these roles is incredibly demanding on mental stamina, and usually coupled with other features in a project. To be honest, if these guys are behind, then you’re better of postponing the release as the problems these guys create, can propagate everywhere! Alcohol is a good metaphor for crunch. It’s great and entertaining when enjoyed in sensible doses and the dose sizes are different for everyone. This has happened multiple times and in different scales for me. A long term overworked but paced workload created the same issues, but they took longer to become noticable, whereas the following story shows the realism of short-term overtime followed by no recuperation.
Last year there was an event, and I was asked to put in some extra hours to get a demonstrable feature, and I was promised time off if I managed it. At the time I was fresh and hadn’t been doing extra hours for a good portion of time. The task was to make a demonstration of an air strike. So, I worked sixty hours (twenty hours extra at the time) and over delivered with an airstrike, artillery, and smoke artillery with custom made sounds, particle effects etc (good ol' feature creep) instead of just the airstrike. I finished on the Friday and genuinely surprised myself with just how much I managed to do in such a short sprint. I felt superhuman. I asked if all was good for me to relax over the weekend which the response was “Yes all good now mate” or something along those lines. The Sunday morning, I get a request to fix a separate feature and so on Sunday, after one day of rest and then all through the next week I’m struggling with that one feature. The feature isn’t using anything new or doing anything fancy really, but that one thing took four days of work... What on earth happened? Had I lost my superhuman powers?
At the time, I was blaming the previous coder, the software, the feature itself and was just very negative during those days as progress was not as fast as it was the week before. But the underlying code and software hadn’t changed. Very simply, I failed to perform as well as I had because all my brain wanted to do was recover mental stamina after overexerting the week before. Just like any muscle, overexerting the brain will force it to output less power no matter how hard you want to push it. Yet we never feel the strain as obviously as we do any muscle...
Commitment
I was reading about the language of commitment and will take a lot away from it. One thing that I knew I was doing but never had the sense to correct is the language I use when I disagree with something but won’t openly admit it. I can’t tell you the number of times this has happened. I highlight a new request as nearly impossible in the timeframe and get told “it needs to be in” and so I just respond with “right” … The realisation was so strong I nearly woke my neighbours, vibrating out of the bed in fury at myself. I am agreeing, but only with the fact that it’s been requested even though it’s impossible. But what I’ve also done is claimed ownership of the responsibility to do the impossible. The number of times I’ve “performed miracles” because of this…
What should I have done?
Very simply, I must not take responsibility early. If it’s impossible and needs to be in, then what do you want to cut? And after that is the potential for more time to fully implement that feature after investigation/refactoring which means more cuts from the current plan to add this new request. If I don’t set this foundation to the request, it becomes my responsibility far too quickly. I need to turn the responsibility around so that the cost doesn’t become my problem. Time is not mine to control and the time has already been pre-emptively charged with estimates. The time must come from somewhere and I have already charged mine. It sounds cutthroat but the sooner you accept responsibility for something like this, the sooner you lose control of time. Time is the most important resource you have. Maybe you have some budget under your control, but I’d argue that money is still not as valuable as time in our profession. We can work wonders with time and from experience, I will always choose time over money.
Hope
Hope is the worst one. Hope gives a false sense of reality. We hope things all the time, but we need to act on what we know, not what we hope for. While I’m putting together estimates, I often wonder if I’m overestimating and then in the same breath, wonder if it’s underestimated. In my most recent estimate for roughly eighty days of developer time for a product (three programmers, last milestone, lots of holiday, and about a month and a half in real time), I was convinced I gave more than enough time. After a week, the estimate was only one day off. Then the next day, we’re almost six days ahead. In programming, there is a lot of unknown. Simple tasks can very quickly become complicated and complex tasks can become simple, not to mention the disparity in your teams abilities when choosing an assignee for tasks too. This makes it difficult to estimate the right amount time and it is critical that there is enough time. Enough time means good work. Not enough time leads to shortcuts, overtime, and an overall poor quality because you’re trying to meet a deadline. The main cause of not enough time is hope, and when planning without enough time, individual features must become hopeful. What I mean by this is that we must not hope that there is enough time for everything. There must be enough time for the core features, anything else is hopeful. Hope is the biggest killer of products according to Robert C. Martin, the grandfather of good practice (Clean Coder if you’re wondering).
But how do you spot hope? Hope comes in all forms. The most prevalent is in the words we use in communication with others, and with ourselves in our head. If you find yourself or others using these words, start planning your time and communicating concerns as soon as possible. “Try”, ”Have faith”, ”Perform another miracle”, ” Not complicated”, ”Easy”. They are words that encourage hope and give you a false sense of expectations by putting your mental state too far forward in time. Plans must be realistic and hopeful plans are not realistic.
This is quite a wordy blog post, and I can only hope you enjoyed reading it as much as I enjoyed exploring the problems I faced in my recent impossible goals. Somehow, I not only hit my targets, I achieved them. But I can tell you now that the personal costs were exceedingly high. That means I was not performing well professionally, and the cost fell on me personally. How many times have you heard "You must look after yourself"?
So what does professionalism look like?
You are contracted to do the work and it’s in your interest to look after the main driver of the contracted work… you!
Keep your goals realistic, be careful what you are committing to and never hope for the best.
Komentar