The SquizLog

Schedule Pressure

What effect does schedule pressure have on developers?

It can motivate developers to put in extra effort or find more ingenious ways of meeting a deadline. However, I think it needs to be applied selectively with caution. Too often, I have seen it backfire.

If the pressure is applied for a short period, for example two weeks, when there is a reasonably high, shared level of confidence in the team's ability to deliver on time, then I think it is warranted.

But it gets back to estimating.

How certain can one be that it will be just for that short period of time? What may happen is that developers will take short cuts in order to meet the deadline, only for unacceptably poor quality software to be delivered. Then a steady stream of bug reports from the customer follow and, if things really get out of control, a serious need arises for repair to a damaged relationship with the customer.

And what led to the schedule pressure in the first place?

Usually, a poor estimate or a deliberately low estimate in order to win the business. I think there is a long way to go in improving estimates for software development. An obvious start is measuring how long tasks really take and learning from those measurements. Working towards a repeatable process. But, as Hacknot points out, that is not trendy or considered too much like hard work.

Perhaps a more honest approach would be to make two estimates for every project. One for what cost we think the potential customer will tolerate and the other for how much effort we think it will actually take. If there is too wide a disparity between the two numbers, we are heading for trouble!

Anyway, back to the likely effects of applying schedule pressure. It is interesting to note that a University of NSW study, quoted in Peopleware: Productive Projects and Teams, concluded that "projects on which the boss applied no schedule pressure whatsoever ("Just wake me up when you're done.") had the highest productivity of all."

Posted to Peopleware, Software Development by Keith Pitty