We knew this, right?

CIO warns many IT workers face dangerous stress: At Share conference, William Cross says on-the-job IT stress is a problem Patrick Thibodeau August 15, 2006 (Computerworld) -- BALTIMORE -- When it comes to testing an IT system, William Cross, the CIO of Seminole Electric Cooperative Inc. in Tampa, Fla., uses an approach that his staff describes as "brutal." But it's a system Cross hopes will avoid sleep-disturbing middle-of-the-night production failures -- part of a larger effort to keep his staff from getting stressed out. (ComputerWorld)

At the risk of stating the obvious: Duh! He goes on to say the reason people make mistakes is because they are working in the middle of the night. I have a much more important question - Why were they working in the middle of the night?

If the project does not require full support (7/24/365) and most initial projects do not, then no one (in general - I know there are those that work better at night, but then they sleep during the day) should be working in the middle of the night. I am constantly reminded about the horror stories during the release of Windows NT and Windows 95 where developers were essentially sleeping in their offices in order to meet unrealistic marketing goals signed off by development and project managers that did not know how to say no to CIOs and others at the C level that were more worried about their image than they were about either the quality of the code or the state of their employee's health.

In this day, if you do not pull the long hours your job could wind up overseas. Fine. Send it there. For the past few months I have been dealing with these overseas programmers and while I am sure there are some that are doing a fantastic job, most do not seem to even grasp the basics of design and coding standards that have been in place for close to a generation because they are just starting to learn the job. Most of the overseas code is currently what has us in the mess of increase security issues.

Perhaps, instead of stating the obvious, CIOs (and others) should think less about what could be and more about what should be, achieve what can be and then be surprised when something rises out of process, rather than trying to drive yet another square peg into a round hole and asking why it is not performing, why it is leaking data, or why it does not do what was overpromised.