Crunch Mode And Making Superstars Average

Posted by Mike Bria on Feb 26, 2008

Sections

Process & Practices

Topics

Delivering Quality ,

Agile ,

Agile Techniques

Tags

Management ,

Professionalism ,

Productivity

A recent set of posts by James Golick and Reg Braithwaite discuss the often overlooked realities of how putting teams into "Crunch Mode" can have undesirable results.  The discussion looks at various ways applying pressure to a team often results in putting your project into not better but worse shape and how teams and managers might benefit by taking a different approach.

The initial postulate posed by James Golick is that "Crunch Mode" initiatives have the ultimate, and ironic, effect of decreasing overall productivity by turning your all-star programmers into average programmers.  Golick's primary assertion is that the habits making your best programmers highly productive in the first place are likely to be the first habits to be shed when the crunch mode kicks in:

That is probably the biggest difference between your great developer and the average developer you went through so much trouble to avoid hiring;  your superstar's priority is the code, whereas the average programmer's priority is going home at the end of the day. When you flip that crunch mode switch, though, priorities change.

When everybody is racing to accomplish a set of tasks for a certain date, coming in to work every day is about trying to get as many of those features out the door as possible in as short a time. The pressure is on.  People start cutting corners.  Processes break down.  People write fewer tests, refactor less frequently.  You have effectively turned your superstar team in to a group of average programmers.

Golick continues by outlining additional reasons why pressuring a team may be likely to have a negative outcome:

Sending your team on a death march quickly leads to programmer fatigue, which nearly always leads to bad code. Moreover, developers are likely to become demoralized, burnt out, lose interest in the product, and perhaps worst of all for you, they'll become resentful of management. Moreover, in many cases, due to nasty bugs, and later hits in maintainability and consequent necessary rewrites, the crunch mode developer is outputting less in total.

The post goes on to offer two suggestions for programmers to heed in order to avoid "Crunch Mode" defeat:

1. Forget about the pressure.  Avoid the trap of trying to save time via neglecting to follow the practices that make you productive in the first place.
2. Just Say No.  The most responsible thing you can do is to ensure your stakeholders fully understand the consequences of demanding more work be completed than you can do without sacrificing quality. 
   

You're the one who is going to have to maintain this nightmare when crunch mode is over (and we know that there's never really time for a cleanup). Your company is going to have to deal with low quality software, and likely a botched release. Everybody loses.

An earlier post by Reg Braithwaite touched on this second point of "saying no".  Braithwaite agrees that, as a software professional, one has a certain level obligation to stand up for the way they intend to execute their craft, but that under many circumstances there exists a point at which they are best suited to accommodate the stakeholder's requests:

I can be swayed into going against my instincts if the person who bears the consequences of the decision insists on following their judgment ...  if [on the other hand] I am asked to develop software that is insecure and places private user data at risk, I will make the personal choice of saying no.

In response to Golick's post, Braithwaite added to the discussion by challenging that many "Crunch Mode" initiatives are not the exceptional, "just this one time" events managers might justify them to be.   Braithwaite asserts that a "Crunch Mode" effort is not an exception if it happens frequently or if it could have been planned in advance, and offers much challenge to what many managers and developers commonly write off as "unplanned things" upon the onset of a "Crunch Mode" initiative or failed project.

I may not know exactly which bug will arise, but I know statistically that bugs happen, that requirements come into focus, and that estimates are just estimates. I do not say to my boss, “I had no idea they wanted a view for this behaviour, I had no idea this other thing wouldn’t work as expected, therefore we need to finish the work without testing.”

I can—and do—expect these things to happen, and therefore I can—and must—plan for them.

For another view on why to avoid shortcuts in agile projects, see this InfoQ news post.

1. Back to top

   Why saying no can be naive.

   by Martin Luther

   I think I’m a pretty good developer (my manager and my payslip tell me so). I also have a wife , two children (one going to university next year) and a mortgage. When it comes to crunch time I don’t refuse to produce a botched release. I have too much at stake.
   
   Maybe I should get another job. But that too is full of risk and – I know – the new company will also ask me to botch up releases so that they can ship on a particular, aggressively planned, date.
   
   Maybe I should just say no like Golick suggests. Perhaps I’m so good that I won’t be sacked (or placed in some backwater department until I go). Most managers like a good worker, but a good worker who rebels can be (and will be) replaced. Skills and experience can still be bought on the market place.
   
   In his original post, Golick uses the example of doctors and engineers. For certain jobs, both of these have a personal liability that comes with the job. This liability overrules the financial concerns and secondly means that it is difficult for an employer to find a replacement who won’t rebel. Result is that standards are maintained.
   
   Should software developers also have a personal liability?

   Reply

2. Back to top

   Re: Why saying no can be naive.

   by Chris Norton

   Your manager's failure to plan appropriately does not result in your personal liability, period. It would be like holding a doctor responsible for a smoker's lung cancer.
   
   No project plan should assume more than a 40-hour work week. It isn't fair to developers, and countless studies have shown that productivity erodes so quickly past 40-hours that there is no real gain to be had. Long hours also result in increase errors and accidents.
   
   Rather than a flat refusal, developers should ask to see the estimate for a given piece of code upfront. If the estimate assumes nights and weekends, you might show your manager an article like the one above, or this onefrom Ron Jeffries. You can explain in a constructive way that long hours will ultimately delay product delivery because of the increased defect rate, and that the shipped code will incur higher support costs which will delay future enhancements.
   
   You can do all this in a way that appears helpful and constructive: you are just trying to find the best path to the goal.
   
   As for personal liability, I think it is limited: developers should be expected to produce output at a level that is consistent with their pay-grade, and comparable to their peers. But that is the sort of thing you measure in aggregate over periods of six months or greater. A manager who demands more than that is not managing, he is slave-driving. You shouldn't be forced to work more than 40 hours if you don't finish on time unless you would be allowed to leave after 20 hours if you finish early.

   Reply

3. Back to top

   Re: Why saying no can be naive.

   by Deborah Hartmann

   Remember that "no" can be said as "yes, and..." as in:
   
   "Yes, I can do that, and here's what experience tells me will result..."
   
   You don't need to use the word no, and
   
   > ... appear helpful and constructive: you are just trying to find the best path to the goal.

   Reply

• Older >