>So I needed to be there to make sure I did everything >possible to ensure a positive outcome. Yep. I once worked for a large, old-school company where a larg

>So I needed to be there to make sure I did everything >possible to ensure a positive outcome. Yep. I once worked for a large, old-school company where a large system had begun to fail. Management decided to fix it by assigning tech folks to 12 hour shifts -- 24/7 coverage! Each shift would report to the next before leaving to sleep. I'm very bad at time-shifting and especially inept without sleep, so I was all but worthless. It quickly became clear that the middle managers involved cared more about making upper management think they cared about the problem than actually fixing it. Finally, they gave up on putting their software factory into full production and instituted more normal hours. The problem was eventually diagnosed and solved. There were two things that were especially sad: 1. The root cause of the problem was that middle management was rewarded for making projects "come in on time" and the technical quality of the work was never evaluated. So, a manager whose on-time project left the codebase very brittle might be rewarded while the manager whose well-designed project was a few weeks late could be out of a job. Specifically, the above issue was caused by a custom framework (Red Flag #1) which made LDAP/DB calls inside a synchronization block. Furthermore, when tracing was finally enabled, the application (which rarely served over 100 simultaneous users) was making thousands of DB calls per second. Since no one in a position of power knew how much had to have gone wrong to get to this point, these "oversights" had no effect on managerial evaluations. 2. The project's post-mortem was initially limited to reviewing the tactics used to fight the fire once it was noticed. I, the ever unpopular guy, suggested loudly that we discuss why we had to fight a fire in the first place. Lucklily, others quickly piled on, and the discussion shifted toward prevention. No wonder I didn't stay there too long. It was as if occasional broken-ness was a given. I just re-read what I wrote, and I sound like some angry code monkey. But, my core point is that the discussion in the article surrounded what a good manager ought to do when developers must work at 3 AM. Perhaps the real question that ought to be asked is, Why do developers have to work at 3AM so often? In the example I gave above, management was GREAT at providing pizza, coffee, and encouragement. But, they were really just covering for organizational ills that allowed such crap to manifest itself in the first place. There seems to be some odd American obsession with timeliness over most other measures of quality. Perhaps it is because it is so easy to measure? The article cited the need to re-work a payroll system at the last minute. Either (1) the payroll update could wait until the last-minute corrections were made during daylight hours and tested appropriately, or (2) the inherent drop-dead date for the change (perhaps a regulatory requirement?) should have led to the system being tested and approved by business users (who understood the requirements much better than the BA) well before the drop-dead date. Either way, something was broken, and it wasn't the manager sitting in the cube at 2AM.