Killing the Crunch Mode Antipattern | Hacker News Reader

Killing the Crunch Mode Antipattern

chadfowler.com

158 pointschadfowler63 comments

This is the oldest battle in the history building anything. I can't even count the number of reason's I've seen make that happen in large companies, startups, homework projects, everything.

- procrastination (trying to get in the right mood/alignment of stars before getting work done)

- burnout

- senior architects forecasting the work of junior people

- sales teams selling the world without consulting the execution team that has to build it from scratch

- management that doesn't know what it wants

- management that doesn't know technical constraints

- management that doesn't know how to manage

- tech teams not knowing what they're doing but being confident they'll figure it out

- unrealistic, arbitrarily set timelines

- realistic non-arbitrarily set timelines

- lack of skill awareness

- lack of self awareness

- politics

- lack of care for the outcome

- greed

- misaligned incentives (compensation for time spent working instead of outcomes or speed of work)

- a really good TV show running at the same time

- lack of team morale or discipline

- perfectionism

- and my favorite:

Team staying till 11pm every day for three months because of a boss who stays till 11pm for three months, trying to outstay them so he can have fun with his mistress.

Until you have the luxury of outcome ownership in place of task ownership, crunch mode is hard to love. When you become a product owner, deadlines become your best friend because they force both you and your team to optimize the work, avoid feature bloat, and get creative about your approach to the problem.

I set a crunch time for myself every day I start working on a new feature. No going to bed until I get a functioning solution, even if it's not the best ultimate scenario. While I'm sleeping, beta users are verifying my assumptions (if they like the feature, I polish it. If not, I've only spent a day in the wrong direction.)

Also, while we're sleeping, our brains will continue to work on things that we're stuck on. It's amazing how many times I wake up with a solution to something from the previous day.

Amazing how many times I dream of code and solve it in my dreams, but that only happens during crunch mode...

Here's a tip: if you have a problem you're having trouble solving, work/think about it a bit before going to bed. It will be fresh in your mind, and as you sleep your brain will churn away at it.

This works for pretty much everything.

Please tell me that final one actually happened...

Yep.

"It makes people lazy and less productive. This may seem ironic, but when someone puts in heroic levels of effort, they start to place less value on each minute. I know that if I work all night, then an hour brain-break mid-day sounds very reasonable. The problem is that these breaks become a habit that can persist between Crunch times."

While I found the rest of the article to be thoughtful and useful, this part sounds like it was written by a pointy-haired boss who doesn't believe his employees can possibly be productive unless their butts are firmly planted in their chairs.

A one hour mid-day brain-break might make many people more productive. In fact, taking an hour for lunch and getting out of the office is a good way to clear you head, and by the time you get back, your brain might have figured out the answers to the problems you had when you left (which might have taken you the rest of the afternoon to figure out otherwise).

If you can't trust your employees to take mental breaks when they need them, then you should be managing assembly line workers, not knowledge workers.

Unfortunately, I had first hand experience on this one, at least for me he isn't wrong. There was a family incident which required a substantial amount of my attention, I'd lost two weeks, and my boss required I make that up.

I went to working from 40 a week to 60. The thing is, I already had trouble pacing myself. I tend to work fast and burn out fast, so 40 hours a week was already a little more work than I am capable of, but those extra 20... The only way I could even perform those extra hours was by extending my breaks and doing less work.

Now that I've paid the debt, the way I perceive my workplace has altered. I'm having serious serious serious problems doing any work at all now. I can't get it out of my head, I know I've got an insanely huge block of time ahead of me that I just can't cope with, even if there's some rushed context.

You're right, he used a poor example: 1 hour brain break is not necessarily unreasonable at times. However, his basic point is very true. Right now I work at a company (clara.io) that has an incredible 8 hours a day culture. Heads down, solid work for a solid 8, and then out the door as if there was a clock to punch. This is an incredible contrast to every other place I've worked at, where 10 hours was a short day, yet in reality we probably spent less time working than we do at clara.io. We'd spend time chatting about politics or local issues, take long breaks, waste time on Hacker News and the like, et cetera. It's really hard to cut that out once you're used to it.

Maybe I misinterpreted what you meant by "solid 8", especially in the context of your reply. Does that mean you don't take lunch?

You're totally misunderstanding what he's saying. It's that these people are kidding themselves and effectively completely wasting their own time.

Instead of working 9-5 being productive 90% of the time, they're working 9-11, but during 9-5 they're 30% productive then make up for it by doing a heroic effort in the evening.

If they'd have just focused earlier, they'd be at the cinema with their friends.

I've been in that scenario, getting nothing done during the day then working hard at home at night. It creeps up on you, to begin with you're working all 10 or 12 hours. By the end of it, you're not.

I think you missed his point (which could certainly have been made better). How I read it was more like this: If you are told/know that you will be working 14 hours today because everybody is in crunch mode, then taking ten minutes every hour to get coffee and relax isn't a big deal, and another ten minutes on HN every hour isn't a big deal, and another ten minutes on email every hour also isn't a bid deal, and now you've spent only 7 hours actually working for 14 hours at the office. On the other hand, if you are told you can only work 9-5, then you will save all the HN time for later, and you will probably ignore some of the less important emails, so that's an extra 15 minutes per hour of actual work, so you worked 6 hours in your 8 hours at the office.

Source: I interned on a military base that had exactly this rule. It really focuses you to know you have x hours, no more, each day.

That's a bit naive. Or rather it's just naive.

The underlying problem that leads to crunch periods is not of planning or accurate estimation. The problem is with the psychology. I'll give you a week to implement something that involves a tiny fraction of research or variance, and you can bet that a lot of people will spend 90% of their time allowance investigating this part and then squeezing the actual grunt work into remaining 10%. So of course it will lead to the crunch! All because the grunt work and known solutions are boring and take the fun out of programming, so any decent programmer will tackle any chance for some research and exploration.

That said, relying on overtime as an available resource during the planning phase - yes, this is bad and it leads to unhealthy work environment. Just ask EA.

Wasn't gonna upvote until you finished with "Just ask EA"

Who is EA? Nothing rings a bell--except for "Elephant Ass."

Electronic Arts, computer games company famous for misuse of overtime.

Electronic Arts

I see a connoisseur of Samuel Beckett assigned me one downvote. My interpretation of 'EA' was likely close to the mark. And a further downvote by a namesake.

That'd be Electronic Arts, who earned a bit of ... unsigned publicity thanks to the blog of "ea_spouse" (http://ea-spouse.livejournal.com/274.html) back in 2004, for instance.

Many thanks. I must stick with my interpretation, as the association is now indelible as it is accurate.

"any decent programmer will tackle any chance for some research and exploration"

Doesn't that depend on your definition of "decent"?

I'd question whether putting research and exploration over a known, workable solution with the end result that you miss an otherwise reasonable deadline, isn't necessarily "decent" behavior.

Learning, investigation and curiosity are good and vital but if the job you're paid to do is to deliver software on time the trade off between that and delivery should be consciously weighed and communicated, not just assumed that the fun thing wins.

(Incidentally, I'm not agreeing that this is the only reason that deadlines are missed - it's one reason but the list elsewhere in this thread contains a lot of truth too, particularly the bit about imposed deadlines which is 100% the case on the project I'm on now).

Related anecdote. I used to do university 5 days a week, 9am to 10pm. Yeah, pretty competitive. Then I worked Friday and Saturday night 8pm-4am.

I finally got a small number of teaching hours which paid way better than bar work (non-tipping country), and thought, great, now I can study weekends too.

Instead, I did absolutely nothing on the weekends. Slept. Hung out with friends. Played guitar. And my productivity, quality of work, and concentration span went way up for the five days of the week. Way up. Honestly, I actually feel I ended up spending less hours in the five days to do better work.

We have a rule at our company, you can leave the office by six pm, you can stay on if you want, but by 8pm you need to be out. We want our guys and gals at their best. So enough sleep and rest, having the time to have a life outside work is a big thing in our company. We always hit deadlines because we have realistic deadlines. We never have crunch mode. Ever. If we spend too many days going home late in a week it's time for us to re evaluate our timeline for whatever it is we're working on.

When I worked at someone else's company I hated these crunch modes we had. And honestly never took part in it. When the time came for me to leave I just get up and leave. People would stare, but honestly it's was not my job to stay for crunch mode because some idiot made impossible promises to the client. After that experience I promised myself that when I had my own company I would never have crunch mode. So far I've stayed true to it.

If you can't change the deadline, there is too much work and you don't wanna go into crunch mode, you have to cut features. I personally use a gant chart and any other planning docs that make sense when scheduling a project. It helps to make my case for cutting features and convincing management of things that we can delay to a 1.1 update. I find that people respond pretty well when I can show them a visual chart with sensible looking numbers and they can also see how hard everybody will be working. I also have a few tricks for figuring out which things can be delayed without a major impact on a launch. For example if your system will automatically bill customers monthly - then you have 30 days after launch to get the automated billing working and nobody will know the difference! Lot's of little admin things like that can be delayed without customers or management even noticing that you are cutting features.

I'm pretty much a stickler for trying to get things done without ever going beyond our standard work week hours. It's usually pretty tough the day or so before a big launch for everybody though - not just the programmers. Somewhat human nature I suppose - some unplanned thing always reveals itself at the last minute.

It's also culture. The only place I hear about crunch mode is Hacker News (e.g. Silicon Valley) and game programmers. I'm in Europe.

In fact, we have the opposite problem: a commonplace deeply-felt entitlement to a decent salary for max 8 hours a day, by the clock, never more, but also never less. This prevents crunch mode to happen most of the time (fortunately), but there's plenty other problems instead, such as a lack of commitment and team spirit, people who don't care about outcomes but just about clocking their hours. Stuff like that.

Crunch mode is pretty standard across the whole U.S. business culture, not just in Silicon Valley startups.

Crunch mode definitely happens in the UK too. (I will leave it to others to decide if the UK is in Europe or not...)

It's probably even worse in banking and law that software development.

In my experience, from a working culture perspective, the UK and Ireland are most decidedly in America more so than Europe.

It happens in Europe wherever there's a startup city. The author is based in Berlin like myself, and this city has a fairly new and growing startup scene. I have many friends working across different startups, and "Crunch Mode" is definitely happening around the place. You notice it second-hand when your friends don't come out on the weekend with you because they're so exhausted they need to rest, or they're still at the office.

I will tell you right now that it is NOT the inability to crunch that is causing that problem. In fact, lots of crunch tends to cause exactly those problems.

In my opinion, there's a crucial issue you have to keep in mind about crunch mode.

Software development is one of the last few cases where you have smart, highly educated people doing the "grunt work". We've automated mostly everything else, or got low-skilled labour doing tasks where more hours map well to more productivity. Developers are the assembly line for software, and it's very, very easy to then take that notion too far. Surely, if you keep the assembly line working longer, you'll get more stuff at the end?

> Developers stereotypically glorify the ability and propensity to stay up all night grinding through a difficult problem. It’s part of our folklore. It’s part of how we’re measured.

No thank you to all that. I'm here to do good work and get paid, not be a hero. If you think this way, you are letting this happen to yourself. Your glorification of working late hours is nothing more than an open door to management exploiting you. That doesn't make you cool or tough or badass or a genius ninja rockstar, it makes you a mark.

I think crunch has very important place in startups. How else would you expel technical cofounders/employees before they exercise their stock options?

Crunch mode is a tool. I have had two successful ones - they were both very similar - we had great communication with the management, clearly defined goals and provided unwind time afterwards - and the company footed the bill.

But the management lead by example - we were working long hours - the boss managed to show up earlier and leave later than us.

The other times I have endured crunch mode (other many layered management company) were trainwrecks.

I've been a software engineer for nearly 30 years. I accept that in this business, crunch time happens. That is, I accept it as long as it's rare.

The boss calls me in at 9 PM to work on a crash, and I'm there till 1 AM? It happened - once in four years in this current job. I accept it when it happens at that rate.

In a previous job, there was an annual trade show. The pace picked up a month before it, and picked up again two weeks before it. The rest of the time, we didn't do crunch time. I was OK with that, too.

Extreme programming had a rule: Never do overtime for longer than a week. Why? Because it makes you stupid. This isn't an assembly line. Your brain has to be working well for you to be effective. Otherwise, you're just creating bugs that are going to take you more time to find and fix. Go for a walk. Go get a good night's sleep. Go do something fun for the weekend. Come back ready to crank.

Does "crunch mode" exist in other complex engineering professions? Civil engineering, aircraft design, nuclear plant design, and so on?

(Genuine question ...)

>"Does "crunch mode" exist in other complex engineering professions? Civil engineering, aircraft design, nuclear plant design, and so on?"

In my experience, not really, not nearly to the same crazy degree that everyone in technology is familiar with.

I've worked close to some large construction projects (hundreds of millions USD) and smaller build-outs of physical infrastructure (ISP stuff).

Off the top of my head, I imagine some of the reasons these projects aren't subject to "crunch mode".

* There's a huge supply chain of permits, materials, equipment, labor, inspections and more that has to be scheduled well in advance and is difficult if not impossible to rush.

When you have some relatively self-contained pile of code it's easy to think a successful redesign is always within reach.

* There are few if any sudden epiphanies or clever "hacks" to be discovered and even if there were, the consequences for using one with some hidden side effect can be literally deadly.

* In construction, labor is backed by the confidence and support of powerful, effective unions. Good luck telling a bunch of steel workers that they're going to have to put in an extra 30 minutes, much less a 48-hour marathon and not get paid.

* Professional engineer is a licensed profession as opposed to technology where it's often an entry-level title that doesn't necessarily mean anything.

I haven't met a professional engineer who didn't have some respect for and ability around process, planning and documentation. All of which are things which go a long way toward setting expectations and building / maintaining realistic schedules and fixing problems as they arise.

Meanwhile. we've all met software, network or systems "engineers" and had to support the code/infrastructure of people who were happy to just "make it work" and move on.

(Yes, yes, this is certainly arguable - I used to argue it against the professional engineers I supported all the time.)

* Software development tends wander much closer to the bleeding the edge than do other forms of engineering. I expect a construction project is far less likely to try and use some novel load-bearing material than a software project is to make a bet on some new framework.

I've worked at various points in a startup, banking and aircraft design/manufacture. My wife is a civil engineer. I've seen Crunch Mode in some form in all of them but the rationale will differ.

For example, my wife did both offshore and tunnel engineering and would work very long shifts plus be on call between them. The main difference with the sort of thing I've done in software is pay: she received overtime even as a professional engineer and this was the main draw, particularly offshore.

In aircraft design, there was never any crunch on the actual design because it was pointless; the review and audit processes went on for years. However, we'd work extended hours for trade shows etc but it was much less common than in banking or the startup.

Meet your deadlines but reduce the scope of the work rather than delay release or lower quality.

Short term thinking in development probably stems from short term oriented management incentives. Of course, for many companies, the short term is all there is.

You want to see what a Crunch Mode Antipattern looks like?

It looks like the Obamacare software system.

Ah yes, a million armchair software project management experts were born with that one.

Let's just say I saw it up close.

From my experience working for a clueless government customer run by armchair software project management experts, I think beat is probably right.

The whole thing has played out as a complete disaster in the press and in public opinion, it's not even worth saying that it was a failure of project management. Of course it was.

> The number one reason teams go into Crunch Mode is that their leaders have failed to understand and/or set realistic expectations for the time it takes to complete a project.

Well... Yes and No. In an ideal world, the team decides how long it would take to complete a project. More realistically, I guess, the team is often given a work to complete before a predefined deadline.

These come up on HN all the time, and I want to defend the crunch. If you have a small group of people working on a startup where everyone knew what they're getting themselves into, and have a lifestyle that allows it, what's the big deal?

Just because you don't like working overtime doesn't mean it's the wrong thing to do.

I think a lot of developers, having grown up hearing stories like this, also see it as something of a rite of passage. It's good for confidence and team cohesion, but I agree with the author that it's not sustainable and no manager should be dictating overtime. If the team wants to push through, that's on them.

Working overtime (here and there) and Crunch Mode might not necessarily be the same thing. The problem is it's hard to break the shackles. Imagine when a new person joins this small group of people. They see you are all working until 10pm, how does that make them feel about their responsibilities of being "accepted"?

It's just not healthy for any sustained amount of time. I don't know what kind of lifestyle you are living when your only activities are sleep (less than you need), eating (less than you should, and/or unhealthy food) and work.

Then what's the big deal about paying them overtime?

It's not just in new startups. Agencies with poor engineering culture tend to do a lot o crunch. INCLUDING in Europe.

I think the article would have more impact on managers - those who can do something about preventing crunch - if it just focused on the "makes you dumber" aspect, and said basically that crunch has the opposite of the desired effect.

By the time the article starts talking about remedies, it loses half its punch imo.

At companies that do "critical" stuff, where defects have safety or $$$ implications, the argument about increased error rates is often convincing to managers, and one reason you see crunch less often there. But at many companies the managers may not care. The management of videogame companies does care about defect rate a bit, but it's not their top concern.

That's good feedback, thanks.

There is a personality type that genuinely loves crunch time. It's a fun rush, like a game of Starcraft. I have always done my best work during these times and I always look back on them fondly.

I wish I worked at a company with a crunch culture.

You can "crunch" by yourself. You'll feel like a hero the next day. Not so much a few years later.

All ya gotta do is just start working all day and night and you'll be crunching with the best of them!

I think I know what you mean though - some companies have a very leisurely pace and sometimes even discourage those who try to work too much or too fast.

No ... work a normal day for your company and if you're going to crunch, do it for yourself. Better yet, organize your day so you get a couple hours for your side-projects that don't feel like you're killing yourself. Those hours add up if you're consistent.

That's roughly what I do, but it's too much fun to call it "crunching". Or is it the lack of deadlines? Hmm. It's a good thing with consulting though.

Not after the first month you won't.

No, you don't. If you really, really want to work all night, then do it on a personal project of your own. One that you control, and might make you money some day, as opposed to some middle manager.

Your daily hackernews article about how overtime is bad. Next.

Reply on news.ycombinator.com