I joined a really cool team of developers. My new boss was Bill Hickman. He was another guy with a lot of software development management experience. The staff was really good. So even with ambitious schedules we were able to deliver pretty well.
Like most managers, Bill's idea to get on track when behind was to work more hours. I guess I can understand where this thought comes from. One might think if a developer can code 5 widgets per week when working 40 hours, they can produce 6 widgets if they work an extra 8 hours a week. Luckily I knew that the extra hours would not linearly turn into extra output. So I just refused and went home after my 40. But during those first 40 hours of each week I produced like crazy. The result was successful software that came in a little later than the original estimates.
Why do most managers like Bill fall for this fallacy? The solution to falling behind schedule is not to institute a death march. The last time I signed up for such madness, me and other key developers were booking 80 hours a week. We did this for months. The result? Failed project. You get tired and you start making so many mistakes that extra hours actually move progress in the wrong direction.
It is not that Bill was a bad guy. He just drank the kool aid of clueless project managers. You got to do your due diligence in managing a project, its schedule, and its risks. Don't expect that adding mandatory unpaid overtime will get you out of a mess you created. We need more developers to fight this insanity, myself included. Note to self: "Just say no".
A Little Bit of Crypto - I have been trying to figure out to "collision resistant" some of these standard hash functions are. It is a tough concept to get my head around. I figure...