Share this: Twitter Facebook Reddit. Like this: Like Loading Leave a Reply Cancel reply Enter your comment here Please log in using one of these methods to post your comment:. Email required Address never made public. Name required. Follow Following. View an example. You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered. Your message is awaiting moderation.
Thank you for participating in the discussion. I think the reason there is this optimism, and ignoring what "could" go wrong - because if we did add it all up, the risk and cost would pretty much freak everybody out and nothing could get done. Its more a case of people ignoring the risks and hoping it works out. Its not just software either. Ask anyone who has built a house, renovated, built a bridge, a building etc.
This sort of problem is not unique to software why do we assume that software projects are so much worse then in other "building" type industries?
I generally agree with this. A few thoughts. Most software schedules are falsehoods and everyone knows it. This is where the problem of crunch time starts. Very few managers know how to measure software output.
They measure costs, but not output. This is what drove the offshoring phenomena. They can't measure output for onshore or offshore projects but they can measure costs so they go with what is cheapest and hope they get a working project. Acknowledging risks gets you labeled a "negative thinker". You can't mitigate risks if you can't talk about them. For others, here it is. Working as an hourly contractor, I am very careful on how much I work each week.
I really try to keep it in the 40 - 45 hours range. To whit: 1. Working more than was promised in the contract, in order to meet a pressing deadline, tends to blow up my clients' budgets. This is more immediately noticeable for me as a contractor than most people I work with salaried employees. Just by observing the results of my work over the years, I know that pushing myself to work more results in lower-quality code: More bugs, less documentation, more corner-cases that I failed to consider.
As a result my client is less likely to want to retain me at a decent hourly rate. Making these observations at a personal level is easy to do; doing so at a group or corporate level is obviously more difficult. The article makes a compelling case for it, although I wonder if many software development companies will take the lessons to heart. Just check out the percentage of housing, sky scrapers, office complexes, bridges, rail construction, and other efforts that are built and finished on or before completion time.
There is a major difference between an industry that has about 30 years of experience vs. They are not, at this stage, directly comparable. Maybe in a parable sense but nothing more. Agile is a prime example of just how different it is. Nobody builds a house, then says alright, here's what I got, what else do we need to do. Nope, everything is planned before and part of the schedule is built in as risk mitigation.
When Henry Ford famously adopted a hour workweek in , he was bitterly criticized by members of the National Association of Manufacturers. Ford spoke glowingly of the social benefits of a shorter workweek, couched firmly in terms of how increased time for consumption was good for everyone. But the core of his argument was that reduced shift length meant more output.
I have found many studies, conducted by businesses, universities, industry associations and the military, that support the basic notion that, for most people, eight hours a day, five days per week, is the best sustainable long-term balance point between output and exhaustion. Throughout the 30s, 40s, and 50s, these studies were apparently conducted by the hundreds; and by the s, the benefits of the hour week were accepted almost beyond question in corporate America.
In , the Chamber of Commerce even published a pamphlet extolling the productivity gains of reduced hours. The current mandatory hours are 9am to 10pm — seven days a week — with the occasional Saturday evening off for good behavior at pm. This averages out to an eighty-five hour work week [sic]. Electronic Arts is no different than many high-tech companies in this regard.
What is management is trying to achieve when it sends employees off on death marches? Management wants to achieve maximal output from employees — they want to produce a good product as cheaply as possible. They also want to avoid hiring extra resources that increase the cost of the finished goods unless absolutely necessary. On the surface of it, Crunch Mode looks like the most obvious and logical way to reconcile these two desires.
To express that view as a simple equation, we can write:. Where O is total output, X is the given output during a benchmark number of hours, designated by Y , and t is the actual number of hours worked. In this hypothetical situation, increasing time t is the simplest way to increase output O.
That assumption may be valid in the limited case where the hours of work are extended over a brief period, for example, to meet a looming deadline. But research — and long experience in other industries — have shown that the limits to such overtime spurts are reached sooner than most people realize.
And when those limits are reached, the spurts turn into bogs. A more realistic view of worker output would take into account the changes in hourly output that result from a change in the length of the working day. Those changes result mainly from two sources: simple physical and mental fatigue that occurs in the later hours of a long day, and accumulated physical and mental fatigue that builds up over an extended period of long working days.
Where O is total output and P represents the changes in hourly productivity that occur over times t 1 — t n. In this equation P is a function, not a constant. P will vary by worker, because some workers produce more than others. P will also vary by hour, because humans are not machines and do not do exactly the same amount of work in hour 14 of a job as they do in hour 1. Sidney J. If On hours are worked, the total value produced is the area Onda.
Observe that the height of the curve P represents worker productivity output per unit time at a given number of hours worked per day. In fact, after b, each additional hour worked produces negative value.
How can this be? Thus it incorporates both simple and accumulated fatigue into its model. At first the declines in output per hour simply reflect the effects of fatigue on both quantity and quality of work performed toward the end of a given day.
But eventually daily fatigue is compounded by cumulative fatigue. That is, any additional output produced during extended hours today will be more than offset by a decline in hourly productivity tomorrow and subsequent days.
Or output can turn negative as stupefied employees commit catastrophic errors that destroy previously completed work or capital. Over time, the worker works more slowly, and makes more mistakes. This combination of slowdown and errors eventually reaches a point of zero productivity, where it takes a very long time to produce each widget, and every last one is somehow spoiled.
Assembly-line managers figured out long ago that when this level of fatigue is reached, the stage is set for spectacular failure-events leading to large and costly losses — an expensive machine is damaged, inventory is destroyed, or a worker is seriously injured. In terms of knowledge workers, a programmer produces more good code and fewer bugs when well-rested.
We take the first hour or so of the day getting into the groove. The next few hours tend to be our best ones. Later in the day, as we get tired, we get less done per hour — it takes a long time to fix a simple bug or add a simple feature that we would have handled in minutes earlier in the day.
Most software schedules are falsehoods and everyone knows it. This is where the problem of crunch time starts. Anyone who took business studies or media studies at school should be aware of the law of diminishing returns. Finding out that the company just hasn't scheduled resources properly, has let projects slide without correction and expected that they'll get "magically caught up" at the end is just lunacy.
Just by observing the results of my work over the years, I know that pushing myself to work more results in lower-quality code: More bugs, less documentation, more corner-cases that I failed to consider. The more demanding the cognitive task, the more important sleep and relaxation are.
I wonder if one thing that distinguishes successful startup founders is that they are immune to some force that limits the amount of productive work that other people can do. Software development is hard to schedule accurately because user expectations evolve during the application building process.
0コメント