Programmers are people, too
The Agile Manifesto reads, in part, that the signatories value "individuals and interactions over processes and tools."1 The field of management was revolutionized by "empowering" people to make decisions and take charge of their work, which led companies to realize the importance of hiring wisely.
In my experience, most companies do prize their engineers. No, they're not given CEO-like rock-star status, and we all wish salaries were higher. But engineers do make a decent middle-class wage, and in these days of nearly full employment in our industry, businesses fearful of losing their developers generally treat the engineers well. I do hear some dramatic exceptions, but most correspondents claim to be satisfied with their jobs.
But there are persistent complaints that never seem to go away. The first of these is overtime; the 40-hour work week is but a dream to many, and panicked overtime is de rigueur at many outfits in the last few months of a project.
Tired people make mistakes. You'd think it would be self-evident that overtime leads to buggier products. Or that safety issues in dangerous environments will escalate when workers take a shortcut that they'd never consider in a less sleep-deprived state.
In my collection of embedded disasters, a common theme is tired engineers. Investigating bodies routinely cite "60 to 80 hours of work a week for months on end" as a contributing cause to a system failure. And, since only the most expensive systems, like space missions, are investigated when something goes wrong, the dollars lost when a weary worker enters the decimal point in the wrong place are staggering.
Most professions suffer from the curse of OT. Doctors get midnight calls from the hospital, lawyers work late in the night to respond to an unexpected judicial ruling, and accountants dread the arrival of tax season. Is this good? I doubt it, and mounting evidence suggests medical mistakes, no doubt at least partially driven by tired people, kill.
Maybe we should plan better, but even the best planning fails when something unexpected occurs. And the unexpected is one of the things we should expect most when designing a new product.
"Unexpected" sometimes comes because we're confused about R&D. One of my top ten reasons why projects fail is because the science is bad: engineers are developing the science in parallel with making the product. For instance, the algorithm changes constantly as we play with the system's chemistry to get meaningful data. That's a sure-fire route to scheduling disaster, and often results in cancellation of the project. I have seen companies go out of business because engineering is so wrapped up in R&D they never get a product to market.
We don't do R&D--or, if we do, we shouldn't. It's either R, or it's D. Sure, development contains an element of research but is mostly about achieving a pretty well-understood objective using known science or algorithms.
It's possible to plan D; no one can schedule R since that intrinsically explores the depths of the unknowns. If research could be scheduled, we'd know when the cure for cancer would be available.
Although it's possible to plan development, it's impossible to be perfect, so overtime will never go away. Wise managers, though, understand the costs.
Circadian's Shiftwork Practices 2005 survey found that productivity can decrease by as much as 25% when workers put in 60+ hour weeks.2 Clearly overtime leads to diminishing returns for everyone involved.