Slashdot Mirror
Why Crunch Mode Doesn't Work
so sue mee writes "There's a bottom-line reason most industries gave up crunch mode over 75 years ago: It's the single most expensive way there is to get the work done. When used long-term, Crunch Mode slows development and creates more bugs when compared with 40-hour weeks. Evan Robinson has an article at the International Game Developer's Association site talking about the harsh realities of crunch time, and why the gaming industry should stop using it." From the article: "It is intuitively obvious that a worker who produces one widget per hour during an eight-hour day can produce somewhere between eight and 16 widgets during a 16-hour day. As we've seen, that's the essential logic behind Crunch Mode's otherwise inexplicable popularity. But worker productivity is largely dependent upon recent history."
Look for other work with better hours.
Don't stay there poisoning yourself.
When you find work with better hours, tell your boss you want better hours or you're taking someone else's job offer. If you can't do that, ask your boss to consider reducing your hours in exchange for a pay cut.
My stepmom did that, and it worked to everyone's benefit. She asked for a 10% raise and a 20% reduction in her salary in exchange for a four day work week. Would your boss like to reduce the amount he spends on salary?
There are no trails. There are no trees out here.
Quite true. And one of the mistakes management makes is hiring people who can't or won't estimate correctly. On prefectly reasonably well-run projects I've been on, things don't get done because some hot-shot lone coder tells management he (and it's always been guys in my experience) can do in half a day what will actually take 3 days from start to completion of integration and testing. Sometimes they just plain don't actually know how long things take. Often, the only portion of the task they think of as taking time is typing time. These wishful thinkers typically type in the change they think is right and check it in and call it done.
If this sounds more like the coder's fault, let me assure you it's not. Miss an estimate once or twice, OK. Nobody is perfect, you learn and move on. Consistently fail to estimate correctly and management needs to take notice. Either pull that person out of the critical path (so missed deadlines don't hurt so bad) or have someone else who has shown better estimating ability size the task and use that number.
If, after 12-18 months of work, management is still letting someone who makes committments he can't keep blow the project's schedule, that's pretty much professional malpractice in any real profession.
Management isn't stupid enough to cut development time in half, but shaving a day or two off of a three month schedule isn't that big of a deal.
We had been working for 15 months of a 24 month project when the newly hired marketing team finally presented a complete product spec (the previous marketing team had been fired because they couldn't produce a sane product spec and we spent our time running around in circles). We did several estimates on the spec the provided and came up with a range of estimates for a nominal schedule of 22-24 months, +/- 25%. We also figured that we could reuse a good sized hunk of what we'd already written and guessed that that would save us about 6 months, leaving us with 16-18 months of work to complete.
But the original schedule had us finishing in 9 months (remember, we were already 15 months into this "two year" project).
They chose not to alter the schedule. Or substantially alter the spec. i.e., management was stupid enough to "cut the schedule in half". Hilarity ensues.
We ship two months late, and what we ship sucks. Most of the internal data-management frameworks were left half-baked so that developers could spend more time working on screens and reports, which means that even minor changes are painful; performance is pathetic; the UI abuses the user in several ways; and it has errors in data management that can corrupt customer financial data.
But you can't teach management a damned thing about how to write software. They're the ones in charge, so they're the ones who have to tell us how to do our jobs best. Right?
Regards,
Ross