Monday, January 16, 2006

Look Ma! I work 80 hrs/week

Having worked in IT for some years, I still do not understand why some developers work more than 40 hrs/week.

Is it because, those developers

  • love developing that 40 hrs/ week is not enough
  • like to brag that they work more than others
  • want to impress the management team
  • are incompetent that they need more than 40 hrs/week to finish their job

I have no idea.

Anyways ,if you think that working more than 40hrs/week is a good thing, does it mean developers working only 40hrs/week are bad?

8 comments:

Jason Yip said...

I think it's clearer if we replace "80 hrs/week" with "while I'm tired".

Muthu Ramadoss said...

Working hours doesn't matter as long as we get the work done.. Hmmm.. and i know managers have learnt the art of assigning twice the amount of workload for a given time.. and the developers are forced to work overtime.

Dave Kirby said...

I once worked in a amall company where working stupidly long hours was the norm. Eventually the developers got fed up and demanded that they be paid for the overtime they put in, otherwise they would work to the hours they were contracted to, and not a minute longer. The management gave in and agreed to pay for overtime. Suddenly much of the need for long hours went away virtually overnight and we started to get more reasonable deadlines.

MÃ¥rten Gustafson said...

It is my conviction that overtime should always render a clear economic cost, as Dave Kirby writes, or management will never appreciate it, consider it a problem, or even think about it...and you won't get extra pay ;)

Anonymous said...

Sadly I'm in an environment which thinks leaving anytime between 5-6:30PM is tanamount to "banking hours." Despite the fact that I'm there at 8:30AM, eating lunch at my desk, and getting stuff done, there seems to be a mindset that working later means you're getting more done, and are even more dedicated. All this while claiming to be an "agile" shop!

I've put in 100 hour weeks only to be rewarded with a small gift certificate for less than $50... obviously even close to approaching what I would have gotten in salary for this extra time. Sigh.

David Koontz said...

I completely agree, several people I know from college work at places where they put in more than 40 hrs/wk and they are ok with it! I never understood how they can value themselves so little as to give away their time for free (we're all salaried).

Henrik said...

The really sad thing is that most of that overtime never does the project any good.

Think of it this way:

A project can be seen as a process for transforming ideas to software. This process har several steps:

[Idea] ->Analysis ->Design ->Coding ->Unit Test ->Integration Test ->System Test ->Acceptance Test ->[Software]

Every idea has to travel through this process to become a feature of the software. The different stages in the process have different production capacities. That is, during a given time period (an iteration, in sane projects), the different stages can transform a different amount of ideas. Let's measure the ideas in Use Cases. You may have something like this:

[Idea] ->Analysis(12) ->Design(8) ->Coding(6) ->Unit Test(14) ->Integration Test(20) ->System Test(4) ->Acceptance Test(5) ->[Software]

What is the maximum production capacity of the project? It is 4 Use Cases per iteration, because that is the capacity of the slowest part of the system.

Increasing the production capacity in other parts of the system, for example by having programmers work overtime, does not help. All that happens is that piles of work builds up in other parts of the system. Such piles of work, inventory, are a bad thing. They block, and clog, and slow things down.

It is also bad from a business point of view, because piles of inventory in the system reduces the return on investment:

Return On Investment = (Throughput - Operating Expenses) / Inventory

In the example above, the only thing that can make the project go faster is to increase the capacity of System Test. This can be done several ways:

* Bring in new testers
* Move people from parts of the project with excess capacity to system test
* Reduce the workload on the System Test people by having the programmers write automated Unit and System Tests

Just to name a few options...

In a similar way, it does not matter where the bottleneck is, you can always find several ways of elevating the capacity of the bottleneck that does not involve overtime.

Besides, if you do an analysis of what happens to productivity and defect rate when people have worked overtime for more than a week or two, you will probably find that the project moves slower than it did before the overtime was instigated.

Brijesh Khergamker said...

Becayse of the reason you stated above and also because they overcommit since they cannot say "no" effectively.