Archive for September, 2008
It was rather nice. For a few minutes earlier today, I was able to experience the designer’s perspective of Blend. We had a bug filed on one of our common controls’ visual appearance, and a designer and a developer were pairing on cleaning it up. They asked me how to structure something, and I was able to completely restructure the UI model of that component without making a single functional change. Yay for Expression Blend living up to one of its promises. Next step is to figure out how to make the experience more common, and help bring the silos closer together… let’s make multi-grain! (err, that was really dumb, but once typed, it was hard to delete)
Every few months something triggers a series of thoughts in my head about overtime practices, behaviours, and incentives. Every time I think about it, my thoughts come back to a question of the relative incentives in the way our software development system. On many teams, the management group has the authority, while the developers have the ultimate power. The people with the authority have an easy answer: demanding overtime is a no-lose situation until the developers quit out of frustration. The developers, on the other hand, have two options: do the overtime, or quit. There is no incremental pain to the management team, while the developers suffer all of the incremental pain.
How do we fix this?
Neither extreme seems appropriate. There really are circumstances in every business where overtime should be required, because the value to be gained exceeds the costs inherent to the overtime. When there is little or no incremental cost to management, the value will always exceed it. Thus, maybe the question becomes “How do we set a meaningful cost of overtime?” A few options could involve paying out overtime (direct financial cost), comp time (borrowing time), or even trading overtime for allowing developers to choose a week’s worth of internal improvement work (options/control cost). (This third option is exciting to teams that want to produce better code but have been in “rush to release” mode for too long).
There is no general solution, I fear. Any solution needs to account for the personal situations of the developers and the project.
One thing I do know for sure: there is much less bitterness when the managers are in the building on the weekends too. There was one time on our last overtime drive when there were three levels of managers (the last of which reports directly to the CEO) there on a Saturday, just to support the developers and make sure nothing was blocking.