Mythical man month says that even if longer hours have diminishing returns, the organizational overhead from adding people to the team is worse - fewer people with longer hours is the better alternative.
Here I will quote a HN post which quotes a secondary source which analyses mythical man month
"From a business point of view, long hours by programmers are a key to profitability. Suppose that a programmer needs to spend 25 hours per week keeping current with new technology, getting coordinated with other programmers, contributing to documentation and thought leadership pieces, and comprehending the structures of the systems being extended. Under this assumption, a programmer who works 55 hours per week will produce twice as much code as one who works 40 hours per week. In The Mythical Man-Month, the only great book ever written on software engineering, Fred Brooks concludes that no software product should be designed by more than two people. He argues that a program designed by more than two people might be more complete but it will never be easy to understand because it will not be as consistent as something designed by fewer people. This means that if you want to follow the best practices of the industry in terms of design and architecture, the only way to improve speed to market is to have the same people working longer hours. Finally there is the common sense notion that the smaller the team the less management overhead. A product is going to get out the door much faster if it is built by 4 people working 70-hour weeks (180 productive programmer-hours per week, after subtracting for 25 hours of coordination and structure comprehension time) than if by 12 people working 40-hour weeks (the same net of 180 hours per week). The 12-person team will inevitably require additional managers and all-day meetings to stay coordinated."
Quoting TMMM as a justification for product death march? Wow.
A programmer who works 55 hours a week will produce twice as much code - but for how long? Once fatigue settles in (a few weeks in), you're back at the 40-hour productivity levels, just paying it at 55-hour rates (and organizational overhead for overtime, oooh boy!), plus burning out the developers (and organizational overhead for employee churn).
Your assumption is that 55 hour weeks are sustainable: just change this number in the spreadsheet from 40 to 55, and voila! And while we're at it, why not 80? Why not 200? Very PHB-ish, in my unhumble opinion.
One of the points of TMMM is that communication and coordination overhead is a cost and a risk and that it grows exponentially in relation to the number of programmers you have. So, you won't get double the productivity out of twice as many programmers (unless they're on unrelated projects--but more projects == more overhead as well).
200 hour weeks would be quite unsustainable, indeed. Forget not sleeping, where do you get the other 32 hours?
I was wondering whether anyone would catch on ;)
Anyway, I wasn't arguing that more developers is easier (I do believe it might be better) - I was saying that piling hours on top doesn't scale either.
MMM is actually an important part of the answer, and it is unfortunate that it was presented this way (death marches are deprecated for their own reasons.) The right way to think of this is to consider four people each working two hours a day on the same problem. Sustained effort and focus matter.
This is most true for tasks that are more intellectually demanding, like the development of large-scale software (which is what Brooks was writing about.) The more routine a task is, the easier it is to divide it up (though that is rarely to the benefit of the worker.)
Maybe it's because I'm a little bit over forty, but for me only a few days working 10 hours a day (plus a significant commute) decreases my productivity significantly. That is at least if I have to work on more that one project at a time. If I don't have to switch tasks and it is relatively straightforward work I can probably manage for a few weeks, but not much longer and I know that I'll definitely hate my life.
If the project is fun I can work two times as long without fatigue. For example if I think this is important and my effort personally can make the difference. Or if I am using a new technology or something that feels like a "portfolio" piece.
I'm naturally a sprinter type, so I tend to set up my work the same way. I tend to work more in the winter (55+ hours) since there isn't much else to do anyway, and work less during the summer (40 or less). I'll also work like you suggest for multi-month stretches and then take a few weeks off and go on vacation.
I've tried the steady working, but I just do not operate that way. When there is work to do I do it, and simply have a hard time sitting still or concentrating on something else.
I'm fortunate to be in a field and with a company that is flexible in this way. I also really like this method. When I'm on vacation that is my 100% focus. I'd much rather work a lot and then completely unplugged instead of always working even on vacation.
At which point they ragequit. But hey, never mind the burnout, let's just find another cog for the machine. Never mind the ramp-up cost - fifty-five hours a week, yeeehaw!
I wouldn't be so harsh. If you are young, and if you breathe, drink and eat your product, this could be awesome. None of that lasts forever, of course, but if it happens - what a time to be alive! Not a place for everyone, indeed, and not conventional.
If, on the other hand, you are only interested in the product, and/or you have other stuff to take care of, that would be Hell on Earth for you.
do you get a lot of actual work done? I found communication slows things done a lot. waiting on answer from other people seems to be a pretty big bottle neck. I like to have a couple project going at once to be more productive.
I get very little of "real" work during regular hours, most of it goes in meetings, code reviews and of course communication. I code during the off hours essentially two jobs i guess, one I love(coding) makes the other(management) bearable .
Your premise is false. You're assuming that people are working in these situations. In my experience you can get one honest week of 40+ hours out of a team, then you will see people piss away company time on meaningless bullshit.
Study-after-study has shown that knowledge workers are useless after 40 hours a week, yet every body seems to think they are the exception. I'll tell you why:
Because we all know what it's like to work more than 40 hours a week on something we truly love and are passionate about, and we've sustained insane levels of work for a long time on such things.
The problem? Your bog-standard social-media/consumer app is not something your developers are going to be passionate about. They may find the odd project here or there in your company that they truly care about, but for the vast majority of applications your dream/company is work for them that happens to align with their skill set, it's not something they'd prefer to be doing.
I know there are exceptions to this rule, and I've even gotten a chance to land a dream job once. Do you know what a dream job turns into pretty quickly? Something you've mastered, and find boring.
Company runners/founders need to get over the idea that their employees should be as passionate about their company as they are, it's such a BS idea. Your workers, should be loyal, do what it takes to keep your dream up-and-running, and coming up with original ideas to make it great, but they should not be sacrificing their lives for your dream.
All-in-all I think you can still design a great product with two people in less than 40 hours. Hell...I think you can do it in 25.
But what if instead of using the 20% to reduce cost, you use it to increase quality. For instance if you have 100k / developer budget and instead of buying a group of 5 avg. developers[1] for 40 hrs/week, you buy 5 great devs for 32 hrs/week. Then overhead per developer stays the same.
Which team would you bet on? The team of great devs at 32hrs a week, or the team of decent devs at 40 hrs a week? You hear about the 10x developer, but if a 1 in 10 developer is even just 1.3x they end up being a better deal at 32hrs a week than avg devs at 40 hrs a week.
[0] Think of an average developer as the avg developer you work with, and the great developer as the best developer you work with.
I would bet on the team who has the best marketing plan and support package because quality at point of sale is rarely the differentiator in a company's success.
I think that usually in these discussions, the money saved (the 20%) is intended to be used on other things than development.
It's a pipe dream. The "saved" money is eaten by fixing the crappy code written at 4 AM, three months into crunch mode. Only works if you can bully the developers into unpaid overtime.
You can't ship a product that isn't finished, and programmers with unfinished projects can't start new ones.
Let other programmers fix the bugs and charge it to support after you release it. Send your main programmers onto the next project. That's how commercial software works.
> Let other programmers fix the bugs and charge it to support after you release it. Send your main programmers onto the next project. That's how commercial software works.
That's how some commercial software works, but less and less. It's a dying model.
That strategy represents two bets: 1) You can shift a lot of the costs from before release to after (in the form of tech debt), and 2) people will pay you a lot up front before they figure out that your product is buggy and that you can't innovate any more.
That could work with packaged software where you can market the hell out of it and get a lot of people to buy it once. It doesn't make sense for internal software, though. And it mostly doesn't make economic sense for software as a service, where people pay you month by month. With a service, it's better to start small with a core market and then innovate continuously, so people always feel like it's getting better. You can't do effective continuous innovation with high levels of technical debt and your "main programmers" off on the next project. Unless your market has a very high barrier to entry, somebody will spot your weakness, jump in as a competitor, and quickly lap you.
We'll still be dealing with the bad habits from that era for years. But the era itself is over.
Like, not here. Instead we hire contractors from some big contracting agency who pay them nothing and charge us $120/hr, then they proceed to destroy whatever quality was there in the beginning. Eventually it becomes such a shit show that we have to start over again, this time with double the contractors since we're given an impossible schedule to replace it.
Oh, the joys of US salary-exempt work. They did bump up the ceiling on the maximum income that can be compensated for overtime, but in practice it is still below the level of most salaried positions.
I don't actually work the extra hours, I just browse Reddit for a few hours a day. I really can't put in 8 hours of actual work, my brain melts after 6.
I find this to be generally true. I used to think i was just working too hard in the early part of the day, burning myself, and simply needed to take breaks. Its true to an extent, but generally speaking I find I have a "window" where I can get meaningful work done, usually between 9-3. Some days its really long, some days it doesn't exist at all, but most days its about 4-6 hours. I either pad the extra time (and feel like I'm doing something wrong) or stress out trying to be more productive. But in reality, I think the window is simply how creative effort works. Though my current office is pretty good about this in general, I wonder if more companies could embrace it would we develop patterns to maximize and plan around these effectivity windows.
Regardless of the outcome (productivity -> more / less / equal), I would like to see the same experiment in IT or even other so called white-collar positions. I am sure things would be different.
I find this to be true when I don't care about what I'm working on. I wish companies would acknowledge that they aren't providing the most interesting work in the world, and admit when that people can only deal with it for so many hours per week. If I find something within the company that I find interesting, I'd happily put in some extra hours for free, but I'd much rather be working 30 hours per week.
I don't agree with working like this, but I'd expect that you're generally going to get marginal gains from each extra hour worked (up to a point of exhaustion or burnout), especially in the short term, so it might make sense to have people work in this way _occasionally_. I know I've been on "work all the hours available" projects in the past, and I definitely got a lot more done than I would have just working a 40hr week, even if I did feel like cr*p at the end of it.
It makes sense when all your employees are singles without a family or any other obligations outside work. You might want to take into account that your employees who are not, may have to pick up their kids from kindergarten/school, etc. They may not be able to work long hours without letting down their children or damaging their marriage.
You could make crunch optional, but there is some peer pressure ('Look, Johnny is not committed to our project').
These are waters to thread carefully if you want to have healthy/happy employees. Make clear rules ahead of times of what is expected, pay extra compensation for overtime.
Too bad I can only vote once UP for this comment. I fully agree; I have a family, my wife is a doctor and she works on shifts, so I often have to pickup kids and so on.
A huge cost that is often misunderstood is the cost of replacing an employee who leaves because the working conditions (endless hours, regular extra time, bully environment) are not compatible with his/her work/life balance.
My previous workplace was founded upon extra time (I remember our CTO and CEO clearly saying that he expected people to work 50-60 hours per week. The CEO literally said multiple times "these people are young, I expect them to work 120%").
We constantly were fixing issues and problems, we never had time to properly plan and design. Once the CTO told me that he expected our SW to have problems, but since we had no time to fix them or to build better software, he also expected the programmers to be available so fixing production issues when they happened no matter if it was night or weekend. Once he told us that he expected senior developers to check email once a day while on holiday to check if there were no problems.
No wonder that in a few month 3 out of 4 of the senior engineers left the company.
Peopleware talks about this. There is a cost to overtime in terms of lost productivity afterwards and in terms of developer happiness. When developers are unhappy, their work quality drops and eventually they leave. Cost of employee turnover is mentioned as a cost that is actually quite high, but rarely factored in.
They also say that overtime can make sense if its short and a rare occurrence.
An employee who leaves is a tragedy, especially in smaller companies. His work has to be shared among the other (implying even more extra time). Then you have to start a new acquisition process to hire someone new, train him, fit him into the existing group and so on. And if someone leaves because of the company culture, there is the possibility that other will follow, making the cost even higher.
I found a good way to curb crunch is to pay extra for it: Every mandated hour that exceeds the regular work time gets paid 25% - 50% on top, preferably in time off (that is for 8 hours extra a week you get 10-12 hours off the next). This allows for crunch time when needed but provides a strong financial incentive to avoid it. A lot of things suddenly drop in priority from "absolutely crucial" to "can be done next week" when you respond with "I hear you, are you willing to pay a 50% premium for that?".
Also offering help with child-care makes things easier for employees with families. Those are solvable problems if crunch-time is limited to short stints and if both sides are willing to work together.
I fail to understand your post: it's neither a novel idea to compensate extra for overtime nor did I claim it was. I just said that I found this to work well.
I see unpaid overtime as one of the primary drivers of extreme crunch abuse. It aligns incentives in the worst possible way: More work gets done per week (though only marginally at best), project management gets to claim "we're doing all we can" and then, on top it's actually free time donated by the employees at no immediately obvious costs. Not surprising that this sounds attractive.
I've struggled for years trying to get my headspace into the right place to deal with salaried work. I've got a very blue-collar background, and my first few jobs were in those kind of hard-hat & steel-toe boot industries, where you literally punch in and out, and your compensation is directly tied to the number of hours worked. In those situations, the calculus you're describing about "does this need to be done now, or can it be done tomorrow?" already takes place, since unpaid overtime is illegal, and if you need more than 40 hours in a week from an employee, you have to pay the premium for it.
It's less of a salaried work issue, it's more one of people not knowing or not caring about their rights. I can't talk about the US landscape but in germany unlimited unpaid overtime is not legal, still you see that often in work contracts, especially in contracts in startups and web/multimedia agencies. Its especially common where unions and other organizations that could enforce legal limits are weak. I've for example never seen such a clause (and unpaid overtime) in organizations where a strong worker rights position existed.
No to overtime being paid in time off. Many times, they'll gladly let you do that, only to not let you ever use it, assuming they actually remember that they promised it to you.
That's the point of "short-term" - that's weeks at the very most. Of course, a PHB will take this to mean "until the next release, half a year away, that's not too long, no?"
Let's discount that programmers are human begins: let's assume programmers are exactly like rotary tools that can run 12 hours a day, everyday, including weekends.
Every tool has a fixed number of cycles before something gives and repairs need to be made (or the tool written off and a replacement obtained).
Depending on the price and availability of a tool, some businesses make conscious decisions to limit the number of hours they use a tool, so as to extend the life of the tool.
Now if we are to consider that we are the said tools, and once we wear out, the onus is on us to repair ourselves and bear all costs of doing so (because the business "writes us off"), we might have more clarity into pricing ourselves?
If we want to add to that, that we are actually human beings, some more clarity perhaps could be obtained.
This is how the system treats most human beings, as labor commodities to be consumed and discarded. This is one of the dangers of capitalism, compounded by 7.5 billion people who are increasingly unable to find a productive role within the system.
> Fred Brooks concludes that no software product should be designed by more than two people.
That really depends on the architecture of the software. There are thousands of people creating and maintaining device drivers for the linux kernel. The idea that only two people could do that simultaneously, is a bit far fetched when the architecture actually makes sense.
But then again, most commercial software does not have that kind of extensible architecture. Therefore, it is probably true that a commercial software team will never really scale.
It's been a while since I read the Mythical Man Month, but as I recall his answer to your point is to look at things through the perspective of systems and subsystems. While Linus is responsible for the overall Linux kernel/system, someone else may be responsible for the X subsystem in the Linux kernel. Which, from what I'm aware, is an accurate representation of how Linux is developed in practice.
Here I will quote a HN post which quotes a secondary source which analyses mythical man month
"From a business point of view, long hours by programmers are a key to profitability. Suppose that a programmer needs to spend 25 hours per week keeping current with new technology, getting coordinated with other programmers, contributing to documentation and thought leadership pieces, and comprehending the structures of the systems being extended. Under this assumption, a programmer who works 55 hours per week will produce twice as much code as one who works 40 hours per week. In The Mythical Man-Month, the only great book ever written on software engineering, Fred Brooks concludes that no software product should be designed by more than two people. He argues that a program designed by more than two people might be more complete but it will never be easy to understand because it will not be as consistent as something designed by fewer people. This means that if you want to follow the best practices of the industry in terms of design and architecture, the only way to improve speed to market is to have the same people working longer hours. Finally there is the common sense notion that the smaller the team the less management overhead. A product is going to get out the door much faster if it is built by 4 people working 70-hour weeks (180 productive programmer-hours per week, after subtracting for 25 hours of coordination and structure comprehension time) than if by 12 people working 40-hour weeks (the same net of 180 hours per week). The 12-person team will inevitably require additional managers and all-day meetings to stay coordinated."
https://news.ycombinator.com/item?id=3547965