One of the simplest metrics that some managers are actually paying attention to is time at work, i.e. how much time or overtime each programmer spends in front of his workstation. This simplest metric might work for manufacturing-like tasks: when worker spends 50% more time at the production line, he is likely to produce 50% more goods (those typically he wouldn't be happy about it). However, the "more time – more goods" approach doesn't work for complex, intellectually intensive tasks like programming. Everyday every software developer has to write the code that never existed before. It is not just pushing the same buttons as yesterday; a programmer has to literally invent a new thing everyday. And invention needs a fresh mind.
Overtime flaws
Forcing a programmer to work hard when he is tired forces him to:
In short, in software industry "tired programmer" is almost equal to "less thinking, more bugs" and missed bugs might cost a fortune to remove at later phases of the project. Especially if they have to be removed under the similar overtime pressure.
Results vs laziness
Often managers watch the time at work only to track laziness and react on it somehow. Unfortunately in software industry hard work and overtimes are closely related to productivity. Even vise versa, a lot of very good programmers can be peak productive only few hrs a day. Those who want to manage the software project have to learn measuring the work results instead of participation rates. Fortunately close customer-developers feedback loop promoted by all the agile methods is exactly aimed at presenting the work results in the customer-understandable form.
Does your manager track your work time? And if he does, does it have positive or negative effect on the team results?
Comments
Post new comment