8 ms·
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 w
by dustingetz 10y ago
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."
https://news.ycombinator.com/item?id=3547965 https://news.ycombinator.com/item?id=3547965
- PhasmaFelis 10y agoThat completely ignores the documented productivity drop from working so many hours, though.
- timblair 10y agoI 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.
- PhasmaFelis 10y agoYeah, short-term crunch can sometimes make sense, as long as it's actually short-term and doesn't repeat on a monthly basis.
- danieldk 10y agoshort-term crunch can sometimes make sense 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. (Sorry if I set up a straw man.)
- Piskvorrr 10y agoThat'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?"
- tigroferoce 10y agoToo 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.
- JamesBarney 10y agoBut 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.
- true_religion 10y agoI 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.
- Piskvorrr 10y agoIt'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.
- bluedino 10y agoThey are salaried so why would you pay OT? 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.
- varjag 10y agoUncompensated OT for salaried employees is illegal in most of the developed world.
- Piskvorrr 10y agoQuoting 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.
- sintaxi 10y ago> A programmer who works 55 hours a week will produce twice as much code - but for how long? By my experience I would say around 18-24 months.
- Ma8ee 10y agoMaybe 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.
- Mikushi 10y agoI am thirty and I find the same. More than two weeks of heavy days and my productivity plummets until I get proper time off.
- ferentchak 10y agoIf 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.
- br3w5 10y agoMaybe it's the quote lacking context but you're wrongly equating lines of code with amount of functionality produced. I agree however that adding more developers can slow things down but this is partly a result of how software is designed and work divided up.
- iopq 10y agoI 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.
- kochthesecond 10y agoThanks, I am not alone...
- mk89 10y agoReminds me of: http://www.johndcook.com/blog/2013/02/04/four-hours-of-concentration/ http://www.johndcook.com/blog/2013/02/04/four-hours-of-conce... You might also find this interesting: http://www.independent.co.uk/news/world/europe/sweden-introduces-six-hour-work-day-a6674646.html http://www.independent.co.uk/news/world/europe/sweden-introd...
- lloyd-christmas 10y ago> You might also find this interesting This was my summary of it when it was last posted: https://news.ycombinator.com/item?id=11683235 https://news.ycombinator.com/item?id=11683235
- mk89 10y agoInteresting! 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.
- hacknat 10y agoI 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.
- 10y ago
- catuskoti 10y ago> 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.
- DanielDent 10y agoIt'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.
- hacknat 10y agoYour 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.
- Asooka 10y ago> 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 Or, management demands overtime, so we give them overpresence. The project gets done slower, but it's with overtime, so management pats itself on the back how it delivered faster. Chocolate rations get increased to 10 grams per day.
- subhobroto 10y agoLet'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. I invite your opinions and feedback.
- rabidrat 10y agoThis 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.