Managing Software Engineers
by Philip Greenspun (philg@mit.edu)
Sumbitted on: 2000-10-22
CCM Home : ASJ : One Article
--------------------------------------------------------------------------------
Philip Greenspun founded ArsDigita Corporation and was its CEO from inception until it reached $20 million/year in revenue. Currently, he is Chairman of ArsDigita and teaches computer science at the Massachusetts Institute of Technology. Why an article on managing people? And one written by someone with training in computer science rather than business administration? There are thousands of books on the best ways to manage people. Many of these books are excellent, having been written by people who've devoted their lives to the discipline.
Software engineering is different.
Software engineering is different because only the best people significantly contribute to achievement. Traditional management texts assume a distribution of talent among the workers. Each worker is contributing something useful and the challenge is to get each one to perform at his or her maximum potential. In the same factory, the best worker may produce two or three times as much as the average, but all the workers are contributing. In software engineering a good programmer is at least 10 times more productive than an average programmer (Brooks 1995). If a product is being developed rapidly, the average programmers will consume nearly their entire work day just in reading and understanding the new code generated by the good programmers. Thus the challenges of a software engineering manager first and foremost are (1) creating a work environment where good programmers will be satisfied enough to stay, and (2) creating a system via which average programmers can become good. In an ideal software engineering organization, there are still some average-quality people but these should be viewed as being apprenticed to the best people and being taught as fast as possible.
Software engineering is different because people at all levels of the organization perceive themselves to be equally intelligent. Consensus-style management can perhaps work when there is a gradient of perceived ability. Given enough time, the less able workers will follow the lead of the more able workers. One of the paradoxes of software engineering is that people with bad ideas and low productivity often think of themselves as supremely capable. They are the last people whom one can expect to fall in line with a good strategy developed by someone else. As for the good programmers who are in fact supremely capable, there is no reason to expect consensus to form among them. Each programmer thinks his or her idea about what to build and how to build it is the best. (See Kruger and Dunning's "Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments" for more on this topic.)
Software engineering is different because a leaf-node worker is more expert than any manager, even when the manager is a great engineer, in at least the small portion of the system that the leaf-node worker has personally built. This makes it difficult for a manager to engage in a technical argument with a worker. It becomes nearly impossible when the manager's technical skills are weak. The worker can spin castles of complexity in the air and come up with impressive-to-the-MBA excuses for why it has to be done a certain way or on a certain schedule.
Software engineering is different because the organization can't afford to lose the individual productivity of the best people by pushing them into management. A truly great programmer may generate 10 times as much business value as a merely good programmer. Can the organization afford to take someone who can do the work of 100 average programmers and push him or her into a pure management role? Probably not. Can the organization afford to put people with weak technical skills into management roles? Probably not. Once you give Joe MBA a title and ask him to coordinate eventually he will be making decisions that have engineering implications. Thus many of the best programmers are eventually forced at least to assume project leadership and mentoring responsibilites. Since they are still expected to produce designs, software, documentation, and journal articles, the danger is that the new manager will become glued to his or her screen and never look up to see how the project team is doing.
Software engineering is different because measurement is notoriously difficult. The world is full of products that failed due to overly complex and tasteless designs. Yet all of these designs were considered tasteful by their architects. Systems that experts evaluated and found wanting, such as the Unix operating system (1970), eventually proved to have great utility. It is a bit easier to count up the lines of code per day produced by a programmer but if the project was not very tightly specified originally, how do you know whether or not these lines of code are useful?
At this point a skeptical reader might be thinking that, while software engineering is different from line production work or any other endeavor with a manufacturing division of labor, there are similarities with research and development, management consulting, and financial analysis. This is certainly true but there aren't too many interesting books on how to reliably produce results in these fields (one is referenced in the "More" section below).
Ideas to Steal
Software engineering is different but it is not that different. What ideas can we steal from the broader world?
people don't do what they are told
all performers get the right consequences every day
small, immediate, certain consequences are better than large future uncertain ones
positive reinforcement is more effective than negative reinforcement
ownership leads to high productivity
people don't do what they are told
In Bringing out the Best in People, Aubrey Daniels notes "If we always did what we were told, we would eat only nutritious foods, never drink too much alcohol, and exercise regularly." There is thus a natural limit on the effectiveness of written policies and management by telling then nagging.
A corollary to this principle is that people do what you reward them to do, not what you hope they will do. Often, when you look at what is truly rewarded in an organization, you find it is different than what you think is rewarded. Do the managers have an engineering background? If not, they'll probably be unable to perceive when a programmer is accomplishing nothing. So the programmer who does nothing gets a paycheck at the end of the month. Having thus been rewarded for doing nothing, the programmer tries it again the next month...
all performers get the right consequences every day
The natural way to manage is to spend time with people who aren't doing a good job. You help them out. You remind them of the good things that can happen to them if they finish a project or raise the spectre of their being laid off the next time the company needs to improve its profitability. These are probably the right consequences for someone who is underperforming. But what about the people who are performing? What if you ignore them day-to-day? Unless they are getting positive reinforcement from another source, they may stop coming in on the weekends to get a release out the door earlier, stop documenting their code, stop writing journal articles. A top performer won't sink to the level of a problem employee but that person may become average. And in the long run a company with average workers will at best earn an average return on equity.
small, immediate, certain consequences are better than large, future, uncertain ones
An annual review and bonus is not classically considered a very good way to motivate people. It is too far away, especially in a dotcom economy. Even if a worker is able to keep the bonus goal fixed in his or her head for the 365 days preceding the bonus allocation, there is uncertainty attached to it. What if the company is doing really badly at the end of the year? Will there still be a bonus?
positive reinforcement is more effective than negative reinforcement
Like most schools worldwide, MIT practices negative reinforcement at the undergraduate level. If student does not do a problem set by a certain deadline, we give him or her a bad grade. This has turned out to be extremely effective at ensuring that an MIT graduate has achieved some minimum standard. However, the students don't accomplish all that they could. The first term that we taught 6.916, we gave the students one week to do Problem Set 1. It was pretty tough and some of them worked all night the last two nights. Having watched them still at their terminals when we left the lab at 4:00 am, we wanted to be kinder and gentler the next semester. So we gave them two weeks to do the same homework assignment. The first week went by. The students were working on other classes, playing sports on the lawn, going out with friends. They didn't start working on the problem set until a few days before it was due and ended up in the lab all night just as before.
We thus proved the management adage that a deadline just gives someone an excuse to procrastinate and do nothing until the very end.
Graduate school at MIT is different. We want the students to do research, write up their results, publish them in journals, and graduate with a reasonably interesting PhD thesis. If a student finishes some research, the most effective faculty advisors immediately provide positive reinforcement by paying attention, helping design the next experiment, helping to draft a paper outline. If the student finishes a write-up, he or she is positively reinforced by being sent to a conference to present it. If the student finishes a PhD thesis, he or she is positively reinforced by being given a 3-7X pay raise.
The lesson from MIT? Negative reinforcement can work if the organization is extremely tightly managed, if the consequences are small and immediate (usually a problem set is due every week and only represents a part of the final grade), and if the goal is to make sure that everyone comes up to a reasonable level. However, the worldwide fame of MIT rests on research achievements by graduate students. This innovation is mostly supported by positive reinforcement.
ownership leads to high productivity
A related issue to positive/negative reinforcement is ownership. Non-ownership systems discipline those who are not working up to the minimum standard, but they do not offer enough of an upside to truly motivate people. Moreover, non-ownership systems demand a very accurate setting of standards. Ownership-oriented systems include contingent rewards with an almost unlimited upside, and are thus effective at getting as much discretionary effort out of workers as possible.
As an example, in the early days of ArsDigita we had only a handful of customers: America Online, Environmental Defense Fund, Hewlett-Packard, Levi Strauss, Oracle Corporation, and Siemens. We had only a handful of programmers as well and hence the easiest way to divide the work was to give a programmer total responsibility for one project. The programmer owned that customer. If the project went well and the customer wrote us a big check, we gave nearly all of the money directly to the programmer. If any project had gone poorly and we'd been fired by a customer, we would not have had to think very hard to figure out who was responsible (fortunately this never happened while I was running the company!). People worked insanely hard to make their projects successful and their clients happy. More importantly, the programmer who did an entire project by him or herself learned enough to train new people, lead a larger project, etc.
After we grew beyond the 40-person mark, pressures to dilute the ownership aspects of our organization grew. We wanted to grow rapidly--nobody wants to buy enterprise software from a small company, even if the software happens to be open source. As our reputation grew, customers came to us with larger projects. We believed that many of our developers were too junior to handle complete responsibility for these large projects. Our costs went up because we had to coordinate the diffused responsibility. In the summer of 2000, when we had 200 or so employees, one of our clients was unhappy. It took a week just to arrange a meeting among the five managers who bore collective responsibility for the project! Meanwhile, individual productivity fell. It was taking more programmer-months and more calendar months to get things done. On weekend mornings you could walk naked through an entire floor of our headquarters building without fear of embarrassment.
(At the time of this writing, there is a proposal on the table to consolidate some of the separate management pyramids, thus taking us back closer to our original structure.)
Building and keeping a good software engineering team
What is the best way to attract some good software engineers to your organization? Hire a few to begin with. Good people like to work with other good people. This is true in every field but much more acute in software engineering. Why? Consider two management consultants working on different projects but within the same organization. If Consultant A does a bad job it harms Consultant B's reputation to some extent but does not require Consultant B to take any action. Whereas in most tech companies if Programmer A does a bad job it usually means that Programmer B will eventually be forced to use the bad code, read the bad code, and then fix the bad code.
What attracts good programmers? Traditionally the best programmers seek the most challenging problems. They want to work in an organization that is trying to build something important. Programmers have huge and fragile egos. If they are somehow assigned to a trivial problem and that is their only possible task, they may spend six months coming up with a bewildering architecture more complex than the Windows 2000 operating system, merely so that they can show their friends and colleagues what a tough nut they are trying to crack. Another source of ego-gratification for programmers is to have other programmers admiring their work. Open-source software projects thus have a big recruiting advantage over closed-source software companies.
What kind of working environment is necessary for programmer satisfaction? Good programmers want to achieve and therefore removing barriers to achievement is the most important step that one can take in creating an effective working environment. Programmers dread elaborate process, endless meetings, and layers of marketing approval before a product can be shipped. Ideally it would be possible to conceive a product on Friday evening, set up the development environment Friday night, write code on Saturday and Sunday, test on Sunday night, and ship on Monday morning. Maintaining this kind of freedom is a serious challenge as a company grows and its products become more complex. Successful companies such as Oracle Corporation burden their marketing departments with overlapping products rather than stifle programmer initiative. For example, during most of the late 1990s there were at least three different Web servers that you could buy from Oracle, each one backed up by a document explaining why it was the one true path toward database-backed Web site glory.
A good physical working environment is essential. Great programmers get a lot of positive reinforcement from their work itself. They write some code and immediately can see it dance. That keeps them at work for hours that, while they would not impress a taxi driver in Singapore or a factory worker in Guangzhou, will surprise many American business people. When we hired an architect to lay out the interior of ArsDigita's first building in Cambridge he surveyed the programmers and came back shaking his head: "I've never seen any group of people who spend so many hours continuously sitting at their desks."
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.
Your business success will depend on the extent to which programmers essentially live at your office. For this to be a common choice, your office had better be nicer than the average programmer's home. There are two ways to achieve this result. One is to hire programmers who live in extremely shabby apartments. The other is to create a nice office. Microsoft understands this. In the early 1990s they did radio spots with John Cleese as a spokesman. One of the main points of the ad was to ridicule the cheap open-plan offices in which programmers were traditionally housed and promote the fact that at Microsoft each developer gets a plush personal office.
How can an office be nicer than one's home? Let's consider the following dimensions:
social
physical comfort
aesthetic
entertainment
attractive
Social
It is easy for an office to beat the home on the social dimension, especially if the programmer lives alone. If there are people at work at all times of day and night and you've succeeded in building an organization of good people, ipso facto there is always someone interesting to talk to at the office. To exploit fully the social possibilities of the programmers' office, it is important to have informal gathering spaces. At the MIT Artificial Intelligence Laboratory, which has nurtured groups of great programmers for nearly 40 years, the gathering spaces are referred to as "playrooms". These contain sofas and coffee tables, movable in the best tradition of Dewey, where programmers eat, talk, and occasionally listen to presentations. Usually a playroom will have some sort of shared writing surface such as a whiteboard. Note that these playrooms also are an important part of an organization's knowledge management system. You need to give programmers from different projects a place to meet where problems can be discussed and solutions from older/other projects can be suggested.
A social place will never be friendly if it is trapped behind a high wall of security. It ought to be very easy for a programmer to invite a friend over. If programmers are comfortable meeting their friends at the office it greatly increases the likelihood of friends recruiting friends.
An open office plan contributes to making the work environment stronger on the social dimension.
Physical Comfort
A programmer's work environment should be a supremely comfortable place to sit, look at information on a screen, and type. At ArsDigita we accomplish this via providing Aeron chairs, the keyboard of the programmer's choice, and at least two monitors. In the summer, the place should air-conditioned 24 hours per day, 7 days per week. In the winter, the office should be heated and humidified (often neglected). The air should be cleaned year-round with high-efficiency mechanical filters and electronic cleaners so that allergy sufferers are not discouraged from working.
One horrible mistake that we made was letting our architect design the workstations. Each programmer was given a 6'x2' desk, 12 square feet total. Two 21" monitors took up so much depth that there wasn't even room for a keyboard. Immediately we had to toss our monitors and get flat panels (cost about $400,000 extra). IBM had a better architect for its Santa Theresa facility: Gerald McCue. He found that each worker needed 100 square feet of dedicated space and 30 square feet of work surface. McCue also found that programmers needed noise isolation from enclosed offices or high partitions but personally we think this rule is worth breaking in a dotcom world where a team has to work fast and in sync. Better to manage noise by spreading desks apart a bit so that there are fewer programmers in a given area and therefore fewer conversations, fewer telephones, and more opportunities for sound to be absorbed before reaching someone's ear.
Aesthetic
Programmers don't have the same need for wood-paneled expensive plushness that, say, corporate lawyers or investment bankers might. However, the office has to be aesthetically satisfying or it will be tough for anyone to take seriously the idea that the company values aesthetic internal design of computer programs. Similarly, the office has to be finished and well-executed or nobody will believe that the organization is committed to finishing products. In the long run it is impossible for an organization to be excellent in one area and mediocre in all others. So the physical facilities have to look as though they were planned and decorated by someone with taste. Note that this need not be expensive. You could do it with $200 desks from Ikea and a consistent set of art posters on the walls. But an expensive facility with blank walls and boxes left over from the last move screams incompetence. Remember that the overall place has to look nicer than most of the programmers' houses.
Entertainment
It is easy to make an office more entertaining than the average person's home. Most people have a TV at home but they don't have friends with whom to watch it. Nor will they typically have the kind of big-screen equipment that is easy for a company to acquire. In the 1980s students at the MIT Media Lab would gather on quite a few nights to watch movies from analog laserdisks, presented with a very high quality projector. After the movie was over, they'd go back to their desks and work for a few hours, something that would not have happened if they'd gone out to the movies.
The average home cannot accomodate a pinball machine. An office can. The average home can have video games, which are very popular with young programmers, but not people with whom to play. The average home cannot have a grand piano but almost any office can.
Attractive
A worthwhile goal is to have at least one thing that is extremely attractive about the physical enivronment for any particular prospective software engineer. Here's a possible list:
dog-friendly policy
grand piano
climbing wall
indoor garden
aquarium
koi pond
exercise room with fancy machines
pinball machine
Not everyone has a dog. Not everyone can play the piano. Not everyone wants to practice rock climbing. But by having a long list in the same building, there is a good chance that at least one item will be very attractive to a particular person. If a person loves gardens, he or she can be seated at a desk within view of the garden. That person won't value the other items, perhaps, but another employee will.
Change of Venue
You can work on all of the preceding dimensions but there will come a day when a programmer gets restless. Sitting at exactly the same desk every day is tedious. We thought that we could solve this at ArsDigita by using the Internet and our branch offices. We'd encourage programmers from Cambridge to pick up and work at a spare desk in the Berkeley or Pasadena offices for a week or two. The idea did not catch on, however, because it turns out to be disruptive for one person on a team to disappear. One of the reasons we've found open-plan offices effective is that it helps to have one's team members close enough to look casually at what is on the screen.
What does it take to let the entire team pick up and work somewhere else for awhile? A beach house or a ski house within a two-hour drive of their main office. It is kind of expensive for an individual to rent a vacation house year-around, equip it with a DSL line or cable modem, and pack it with enough desks and computers for a team to work. But if you've got a group of 30 programmers and get a house large enough for 6 or so to sleep and work, the cost is manageable. In the winter, a programming team can disappear for a week, ski every morning and work all afternoon and evening. In the summer, a team can spend a week looking out at the ocean... while typing most of the time. It costs more than not having the beach house but a lot less than having employees go off on their own to have fun every weekend and not work.
Turning average programmers into good programmers
It is difficult to hire the most productive programmers in the world. Oftentimes these people are capable, by themselves, of turning out entire products, and thus they start their own companies. If a really productive programmer works for an established organization, that organization will usually take extreme steps to keep him or her. Thus beyond a certain point it is most effective for an organization to develop a strategy for creating good programmers internally.
How does one create a good programmer? Raw materials are important. You want someone with a strong computer science education, a high IQ, and an ability to communicate effectively in oral presentations and in writing. But without the right experience, such a person will never be more than an average quality programmer.
These principles are important in building up someone's programming skills:
A person won't become proficient at something until he or she has done it many times. In other words., if you want someone to be really good at building a software system, he or she will have to have built 10 or more systems of that type.
A person won't retain proficiency at a task unless he or she has at one time learned to perform that task very rapidly. Learning research demonstrates that the skills of people who become accurate but not fast deteriorate much sooner than the skills of people who become both accurate and fast.
Technology shifts force a programmer to go through bursts of learning every year or two.
Look around your organization. You can make a list of the people qualified to design and build a new system by counting up those who've built 10 or more similar systems in the past, at least two in the last year, and that could do the entire job in a month or two if they really had to. These are your "good programmers". Everyone else is a candidate to be turned into a good programmer as quickly as possible.
Learning to design and build software systems requires that the programmer design and build software systems. These can be smaller subprojects for internal or external customers, standalone software system for non-profit organizations, or demonstration systems to be written up and distributed to other programmers. A particularly effective option that is only available in the Web world is to build and launch a free public service. See http://remindme.arsdigita.com and http://towzone.arsdigita.com for examples of one-evening training projects.
Whatever the training task, the pace must be ruthlessly brisk. The learner should be expected to build at the same pace as an experienced developer. The difference between the learner and the wizard is that you expect the learner to make a lot of mistakes. The system as built may be awkward or not handle error cases properly. That's okay. Training research shows that if you get speed now you can get quality later. But if you don't get speed you will never get quality in the long run. We practice this technique in 6.916, Software Engineering for Web Applications, our course at MIT. Each student builds five database-backed Web applications during the 13-week semester. The first few that they build, during the course of the problem sets, are not necessarily elegant or optimal, but by the end of the semester they've become remarkably proficient, especially when you consider that each student is taking three or four other classes.
If you see one of your best people walking out the door at 6:00 pm, try to think why you haven't challenged that person with an interesting project. If you see one of your average programmers walking out the door at 6:00 pm, recognize that this person is not developing into a good programmer. An average programmer's productivity will never be significant in a group of good programmers. If you care about profits, you must either come up with a new training program for the person or figure out the best way to terminate his or her employment with your organization.
Still not convinced? Take a look at the Japanese "code factory" circa 1990. These precisely organized large organizations where each person had his role, however small, were supposed to overtake the American approach where small teams of craftsmen worked in a comparatively disorganized manner. The factory approach sometimes produces acceptable corporate IT solutions but for innovation and successful product development, the craft approach has been overwhelmingly vindicated.
Turning good programmers into good managers
As noted in the introduction, software engineering is different because the organization can't afford to lose the individual productivity of the best people as they are pushed into management. At ArsDigita, for example, a manager who is one or two levels up from the leaf nodes is still expected to write code, develop SQL data models, write system design documents, and write journal articles. Yet managers who are spending a portion of their time designing software or writing documentation are at risk of neglecting their duties to review subordinates' work.
The classic problem situation at ArsDigita is a manager getting lost in his or her own work and failing to review a subordinate's efforts for two or three months. When the review occurs, inevitably the subordinate has either been working on the wrong thing in the wrong way or hasn't been sufficiently productive. At this point the manager is really angry. Three months of calendar time and money have been wasted. But should the manager be angry with the employee? If the manager had reviewed the subordinate every week, the company would never have been at risk of losing more than one week of time and money.
Our solution is to decouple responsibility for review from responsibility for scheduling review. We use administrative assistants to ensure that each manager is scheduled to look at every subordinate's work at least once per week, more frequently in the case of junior employees. It has proven remarkably more effective when a neutral third-party is responsible for scheduling than when people with incentives to shirk are responsible for scheduling.
Management by Consensus Considered Harmful
Leaf-node engineers at every company on this planet think that they have better business ideas than the senior managers. Why not simply turn the company over to the engineers to run? Each engineer has a different set of better business ideas.
Software engineering companies will tend to have a fairly flat distribution of intelligence. The 22-year-old Stanford CS punk that was just hired will be just as smart as the 30-year-old lead engineer who will be just as smart as the 40-year-old CEO. Within a company's technical team, the raw IQ differences are even smaller. If each member of the team were playing the Bach Partitas and Sonatas for Solo Violin, the wrong notes, shaky intonation, and bad phrasing would make it pretty obvious to the novices that they needed to take advice from the experts. But because software quality is tough to measure and software quantity is seldom measured, the novices in a software engineering group are able to think of themselves as experts.
What would be wrong with a completely egalitarian software engineering group? Maybe the entire team really is at the same level of ability. And suppose that somehow the challenge of getting everyone to attack the same problem had been surmounted. Remember what Fred Brooks said in The Mythical Man-Month: high quality systems must be architected by no more than two people.
Getting design input from leaf-node engineers is important for having a good product design. But at the end of the day nobody should be confused as to who is providing leadership. There is an irreducible amount of Engineer A imposing his or her design on Engineer B. This can lead to some harsh-sounding words and bruised feelings. Microsoft is not the self-esteem company, at least if you believe Playboy magazine's interview with Bill Gates: "We hear you're brusque at times, that you won't hesitate to tell someone their idea is the stupidest thing you've ever heard. It's been called management by embarrassment challenging employees and even leaving some in tears." Truly elite organizations can be far worse than Microsoft. Ask a group of surgical interns and residents how much respect they get from the surgeons. Go into a world-class biology department and ask the grad students and post-docs about their treatment at the hands of the professors.
Wherever You Go, There You Are
Performance management textbooks will tell you that workers don't improve unless they get feedback. Joe Widgetmaker should get a nice chart, updated daily, of how many widgets he has produced personally each day, and how many have been built by his team.
Consider the average working programmer's life:
surfing USENET
surfing Slashdot
reading docs
questioning colleagues
writing specs and designs
writing docs
writing code
testing code
fixing bugs
filing bug reports on others' code
attending meetings
helping sales and marketing staff
(For comparison to the grad student life, see http://philip.greenspun.com/humor/graduate-student-emotion-check-list.)
Characterizing this person's productivity is going to require more than one number. But if we don't do it, days or weeks could slip by without the programmer realizing that his or her achievement levels are plummeting. In a company with disorganized or technically clueless managers, the programmer's supervisory chain won't notice the lack of achievement either.
Production of documentation and code is generally measurable by reference to the company's version control system. Bugs filed and fixed are easily tallied by looking at the company's ticket/bug tracking system (see http://www.arsdigita.com/doc/ticket for a description of our favorite open-source ticket/bug tracker). The softer stuff can still be quantified but it will have to be done by humans filling out forms.
Ideally the programmer will get daily feedback, which is kept private unless the individual elects to publicize it. Performance in each sanctioned area of activity will be marked up and scored with a weight. The programmer can then see if his or her crude achievement level is going up or down.
Summary
Building and managing a peak-performing software engineering organization is challenging but extremely profitable. The core Ariba product was written by two programmers, yielding a market capitalization of $30 billion. Microsoft Internet Explorer is a much better browser than Netscape Navigator and yet it was written by a much smaller team: only about 30 developers.
Start by attracting a good core team, perhaps by setting up an organization that enables each engineer to excel along the axes defined in http://www.arsdigita.com/asj/professionalism. Provide a productive working environment and a physical environment that is better than the average programmer's house. Provide daily positive reinforcement. Provide daily feedback showing the programmer more or less exactly what he or she has accomplished, plus a graph for the preceding few months showing the trend. Aim to install a feeling of ownership in each worker.
More
Bringing out the Best in People (Aubrey Daniels 1999; McGraw Hill). 200 pages containing 75 pages of good ideas plus the usual business book filler. But the ideas are genuinely good.
The Mythical Man-Month (Fred Brooks 1995)
Managing the Professional Service Firm (David Maister 1993). In terms of having an equal distribution of ability among all levels of the enterprise, the closest industry to software engineering is management consulting. Maister's work is a classic guide to success in this industry.
"Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments", Justin Kruger and David Dunning 1999, Journal of Personality and Social Psychology
Peopleware (Tom DeMarco and Timothy Lister 1999); page 98 is worth the price of admission, explaining that "the term unprofessional is often used to characterize surprising and threatening behavior. ... In a healthier organization culture, people are thought to be professional to the extent they are knowledgeable and competent." (See http://www.arsdigita.com/asj/professionalism for ArsDigita's independent conception of this idea.) Much of the rest of the book is a celebration of the 40-hour work week and the claim that "overtime" in the long run is never beneficial. If the authors were correct, Silicon Valley would be the poorest region of the nation, with Redmond, Washington the 2nd most impoverished. And Washington, DC would be our great source of innovation and productivity. Peopleware was probably written to help ensure success for internal corporate IT projects where there isn't any competition and delivering three months late won't change much.
Making the Cisco Connection : The Story Behind the Real Internet Superpower (Bunnel et al 2000) -- shows how ignoring the "no overtime" admonitions in Peopleware can generate $400 billion in market cap.
Parkinson's Law (C. Northcote Parkinson 1958) -- how management really works in the long run
A Pattern Language (Christopher Alexander et al 1977) has very interesting things to say about physical space and social organization.
--------------------------------------------------------------------------------
Submitted by Philip Greenspun (philg@mit.edu)
Reader's Comments
A corollary to this principle is that people do what you reward them to do, not what you hope they will do. Often, when you look at what is truly rewarded in an organization, you find it is different than what you think is rewarded.
This is illustrated by the classic business school article:
Kerr, S., 1975, "On the Folly of Rewarding A, While Hoping For B," Academy of Management Journal, Vol. 18, pp. 769-783.
It represents exactly what you are saying.
-- Tyler Pruett, October 30, 2000
Philip, your ideas on rewarding programmers are excellent. However, I don't believe number of hours worked defines a good developer. Programmers get older and have families. Saying that they have to log a certain number of hours in the office is stupid, almost like IBM counting programmer productivity in "K-Locks" (thousands of lines of code).
A good developer can often finish what an average one can do in half the time an average developer can - with less bugs and with better documentation.
A couple of good books on this topic include,
"Software Project Survival Guide by Steve McConnell"
(Somewhat dry - but good reference book)
First, Break All the Rules : What the World's Greatest Managers Do Differently
(Not one of the typical management books - this one has some actual research behind it.)
Microsoft Secrets : How the World's Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People
(A few good chapters worth reading)
-- Anthony Barker, November 6, 2000
... the average programmers will consume nearly their entire work day just in reading and understanding the new code generated by the good programmers
I would argue that the phrase above should be reversed: ".. the good programmers will consume nearly their entire work day just in reading and understanding code generated by the average programmers". If the programmer is good, the code will be elegant, easy to read, and practically self-documenting (not that that's necessary because the good programmer would have also written lots of clear concise comments as well). Average programmers will make a mess of the design and would take anyone more time to figure out what the heck they were thinking.
-- Dion Loy, November 6, 2000
Bricks and mortar still seem to play an important role in programming, even in a profession where much work can be done offsite.
My preferred work environment happens to be my home. However, even with a good background (linux, java, C, C++), a good work history and a monetary incentive (the lowly Canadian dollar), most companies aren't willing to entertain the thought of a telecommute position.
While communication among programmers is important and our modern communication tools are far from perfect, it amazes me that companies are still so focused on employees "being there" rather being focused on what they produce. They would rather pay for relocation and expensive high tech cubicle real estate and measure performance by attendance.
-- darrell pfeifer, November 6, 2000
I agree with the poster above about reversing the comment about time spent understanding others' code. An excellent resource about this concept is Code Complete, by Steve McConnel. Given that (I forget the exact number, but it is well over 50%) of programming time is spent maintaining or modifying existing systems, what makes a good programmer is a programmer who can write code that is very easy to understand for the next programmer to come along and have to deal with it. Easy to understand code is quick to get up to speed on and is also conductive to fewer defects, because a lot of defects can be caused by a later programmer misunderstanding exacly how the existing code works. Just getting the code to work in an efficient manner is not enough. If it is excellent code, but cryptic, then it will waste a lot of time (and money) later when someone other than the original developer has to deal with that code. If the design is good (perhaps not super-excellent, but gets the job done) but extremely easy to understand, then time (and money) will be saved later on. A single good programmer can probably rambo-code out a system faster than a group of programmers, but that rambo code that saved so much time for the first release will come back and haunt all future releases - completely erasing any initial cost savings advantage in the long run.
-- D Goodkin, November 6, 2000
Another excellent book on managing programmers is Weinberg's "The Psychology of Computer Programming". (Ignore the technology of programming in the book, look at the message underneath.)
One fundamental objection that I have to the thesis of this article is that one must sacrifice all non-work life to the coding at hand. While at a previous employer, they had internal studies and some external studies of hardware and software engineers that showed steady declines in productivity after more than 1 month of serious overtime worked. This was at a site that turned out very large custom systems at the bleeding edge of digital hardware and software capability, with very high productivity (3-5x industry average overall), even with large project teams (400+ engineers). Their key to getting things done was by having a strong systems engineering group that allowed the problems to be broken into manageable chunks so that the staff could concentrate on their chunk and not spend huge amounts of time in meetings. They also sent everyone to training on the systems and software engineering process so you knew your way around. We worked an average of 45-50 hours/week and generated quality code at very high rates.
-- Edmund Hack, November 6, 2000
I would like to suggest a correction to the article:
Mr. Greenspun uses the notion of reinforcement in regard to managing people. Alas, he made a serious error when he used "negative reinforcement". I believe that where he uses "negative reinforcement", he should use "punishment" instead.
While I have a degree in Computer Science, I did take an introductory course in Psychology, and the definitions of positive and negative reinforcement and punishment were well explained. In this context:
Positive reinforcement:
A programmer writes a lot of really good code (behaviour), so you give him a lollipop (the positive stimulus), which you expect will increase the likelihood of that behaviour recurring.
Punishment:
A programmer writes some bad code (behaviour), so you take away his foosball machine (punishment), which you expect will decrease the likelihood of that behaviour recurring.
Negative reinforcement:
You hire someone to lash a programmer continuously (the negative stimulus) until the programmer learns to escape it (removal of the negative stimulus) by writing lots of good code (behaviour). This will increase the likelihood of that behaviour recurring. It is hoped that the subject will eventually learn to avoid the negative stimulus entirely, rather than merely escaping it. :-)
Clearly, both positive and negative reinforcement result in an increase in the frequency of a particular behaviour, but punishment decreases it.
For other information on this, simply visit http://www.google.com/ and search for "reinforcement punishment positive negative" and check out the results.
Yes, I know that this may seem nit-picky, but just as we in the computer industry appreciate it when our jargon is used correctly by those not in it, I'm sure the psychologists of the world would appreciate it if we used their terms correctly.
-- Kevin McGregor, November 6, 2000
If you see one of your best people walking out the door at 6:00 pm, try to think why you haven't challenged that person with an interesting project.
I would be more inclined to believe that this person has a life, and is balancing it with their work.
People don't live to work, they work to live.
-- Paul Collins, November 6, 2000
Dog-friendly offices may be great for dog owners / lovers, but aren't as wonderful for people with allergies or even those who just want to be able to concentrate on writing code without having a dog try to jump on their lap.
-- Kevin Scaldeferri, November 6, 2000
I have to disagree with the comments about cubicles being acceptable in the dot com environment so that "people can see what's on others screens". The company I work for provided separate offices. Normally the doors are open so people can interact, and people interact just as much as they do in the open concept offices I have been in. The distractions however, do not occur and everyone is much more productive here than in the other places I've been.
-- Thomas Dean, November 6, 2000
Programmers who are measured based on how late they stay at work will quickly figure out how to excel at staying late without being more productive (e.g. come in at 11:00 am).
This article reinforces many great ideas from Frederick Brooks but, unfortunately, regurgitates a few tired stereotypes. Most programmers that turn 30, get married, have a few kids (that go to bed at 7:00), may as well resign themselves to being put out to pasture.
Here's an idea. Instead of just assuming that it takes 25 hours a week for team coordination and build your management approach upon motivating programmers to work more hours, why not work to reduce the time it takes to coordinate through better management and more efficiency? Isn't that what management really is?
-- Tom Wilson, November 6, 2000
The premise of this article seems to be that, if the workplace is sufficiently attractive, work will become the employee's top priority. While this is true in some cases (e.g. young people right out of school) it is not the case for nearly everyone else for whom family is likely the top priority. And even a very young employee may already be married.
While it is probably possible (and may be advantageous) to run a company filled solely with people for whom work is their top priority, it seems like a very difficult long-term strategy fraught with the danger of burn-out (despite the ski house "vacations" and such.)
Are success and a 9-5 schedule really incompatible?
-- John Siracusa, November 6, 2000
Microsoft Internet Explorer is a much better browser than Netscape Navigator and yet it was written by a much smaller team: only about 30 developers.
I'm surprised to hear this from Greenspun...
-- Anson Ann, November 6, 2000
The article is great, save one persistent misconception -- it is not necessary to work so many hours to be a great programmer. Yes, at times, the great programmers go larval and spend lot's of time hacking code. But the author's comment about seeing your programmers going home at 6pm and making the judgement that they should be challenged to stay longer is quite destructive.
I have worked the 70 hour weeks, it was fun, and we did great things. But there was also some great loss (to friends and family) induced by those long hours. I find it disturbing that the article basically encourages managers to find people whom can be coerced (incented, challenged, pick your euphemism) into working such long hours at the expense of all else.
There are some truly great programmers here where I work who wouldn't be here if management followed that advice.
-- Ron Forrester, November 6, 2000
While I generally agree with most of the material presented in this article, I have to take issue that there is some linkage between working long hours and productivity. As a software engineering manager, I generally found that I had to send people home to keep them productive. After 8 or 9 hours, regardless of skill level programmers lose their edge and cannot concentrate. In some severe cases, really good engineers can burn out. I had one developer working for me who wanted to work a twelve hour day ($$$). I vetoed the idea, my management overruled me, and three months later the engineer, whom I very highly regarded, had a nervous breakdown and was lost to the company.
Another thing that must be taught, and I did not see this in the article at all, is working hard vs. working smart. Unfortunately, there is a lot of grunt work when developing software products. Tools, whether purchased or built in-house can really help improve both productivity and morale. But software engineers, especially the neophites, may not realize this. I always stressed to my teams that if there were repetitive operations being performed, they should think "tool". A lazy programmer is a productive programmer.
-- Brian Berenbach, November 6, 2000
This is a great article on software engineering with plenty of good examples on the difficulties of managing software engineers. Every manager should read this to gain a proper perspective on managing a project. But, I disagree with this one statement:
"One of the paradoxes of software engineering is that people with bad ideas and low productivity often think of themselves as supremely capable."
How can anyone be so arrogant? Maybe these people are so lost, that this is the only conclusion they can accept? Nah...it's gibberish.
On the other side of the coin, how does software engineer find a circle of good programmers, since determining good/great programmers is already extremely difficult? Being a "leaf-node" myself, I am constantly trying to rate the software landscape and trying to determine the next Ariba or Internet Explorer. Some say it's impossible and I'll never find that opportunity. Is it inevitible to always have bad programmers/members on the project? Are we all doomed to one end or another to manage these "bad idea and low productivity" people?
-- David Peng, November 6, 2000
RECIPE FOR CARPAL TUNNEL
"the architect never saw so many ppl sit in a chair so long." i winced as i read this. why? because scrolling with the mouse makes my hands hurt.
I am a guy who would program 100 hrs/wk b/c i liked it. in fact, for a few years i did. for me aD would be a dream. but now it is only that. why? b/c after all this typing my hands are ruined. i cannot use a keyboard properly; only for very short times. fair warning to all aD ppl. once your hands or other health are gone, so is you job. and there are only so many opportunities in radio.
P.S. I have a degree from that other school in cambridge. it doesn't matter when you're disabled. you just get the boot and nobody wants you. you can't be a manager b/c u still have to use a PC. so forget about families, you won't get one.
note -- and you must post anonymously so you don't lose any temp job u might have (atm. pr writing with dragon nat speak, a nightmare to use) where they get the idea u are a dead weight
-- asf asdf, November 6, 2000
A few years back I worked on a project that required long hours. We started out at 60 hours per week; nine months later we were at 120 hours per week (of course, a significant portion was wasted). Morale was not too bad throughout the project, as the company was depending on it, and committed extra resources (dinner weekdays, lunch and dinner on weekends). The results were something less than great: the product was very buggy when it shipped, and it resulted in a significant market loss. More than 50% of the core team left within three months. There was at least one divorce.
This is an extreme example, but I have found in several different environments that extended hours are counterproductive, more often than not.
-- John Wilkinson, November 6, 2000
Where does Greenspun get the idea that coordination time, etc. is constant while coding time is not? The math he uses to calculate that 55 hours per week is 2x as productive as 40 hours per week is incredibly sloppy, especially considering how he uses it to justify firing workers who leave at 6.
I expect there's a lot of variance from the 25-hour figure he pulled out of thin air, mostly in the downward direction. 5 hours would be more typical where I work.
Sadly, there are probably some managers out there who will take Greenspun's advice. Probably the same ones who get alarmed when 40% of sick days are taken on Monday or Friday.
-- Bruce Lewis, November 6, 2000
I think two views can be seen on the issue of working long hours:
Measuring the number of hours worked as a means to measure productivity is totally wrong. The only thing that should count is when the product is shipped, and that the employees are fit for the next project.
The suggestion that people that leave by 6.00 are either understimulated or won't grow is very dangerous. I'ld rather have a good programmer leave by 6.00, knowing that his wife (yes, many programmers actually do have both friends, SO's and children) won't hate his work and that he will return the following morning, rested.
The second view is that the company really don't care about the long-term risks of having to replace employees as they get worn out by the hard work. From a HRM perspective, it is wrong, and from a long-term economical perspective, it is dangerous.
But, if the goal of the owners is to produce a couple of killer applications quick, and then cash in on the sale or IPO of the company, that's really the way to go!
/Fredrik Lundström, Software designer
-- Fredrik Lundström, November 6, 2000
Everything in Philip's article is dead-on, except for one MAJOR issue: working your top people like dogs is the fastest way to have them find the door.
Burnout is a fact of life, and it happens to the best of people. If those people are your best people, you're in big trouble.
A characteristic I have seen of the top-end programmers is an ability to self-regulate. They'll get what they're working on done when it should be done (remember, no-one can accurately schedule SW eng problems beforehand, to paraphrase Fred Brooks). If you take away the freedom to self regulate by forcing continual ridiculous hours, they're going to leave.
After all, if they're working 40 hours, they're still producing the equivalent of 400 "average programmer hours". Does anyone really want to lose that?
-- Stephen Drye, November 6, 2000
Overall, I thought the article was a good one, except for the part about "long hours == productivity". I think many of the issues people have raised about that point are right on, but I'll add one more:
Before I got older, got married, etc., I used to work much longer hours. In my experience, being at work for more hours did NOT increase my productivity. I noticed that most of the engineers who were working those long hours were spending a lot of time talking, surfing the web, playing pinball or air-hockey, etc. Your article hints at this when it discusses the need for making the work environment more comfortable and entertaining. If engineers were doing nothing but working for those 70 hours, why would they need entertainment while at work?
-- Andrew Shebanow, November 6, 2000
It is true that 70 hrs/wk can cause health problems if poorly planned. But 70 hrs/wk in a quality low-stress environment is far healthier than 40 hrs/wk in a bad-quality high-stress environment. That is why many people work 80hrs/wk in small companies and are happy wherease they would be miserable at 40 hrs/wk in large ones. It is the manager's role to eliminate the stresses to maximize health and productivity.
The key underlying factor is the amount of stress on the individual which will break down the individual at their seams, either mental or physical. Stress may be in unclear job demands, separation from family, disorderly work environment, lack of creativity, etc. Simple quantity of labor is not the highest workplace stressor (although it is a symptom that often exists in high stress environments). To reduce stress employees must be part of a well-planned process.
Speaking from experience, carpal tunnel and musculo-skeletal disorders can be avoided through proper programs of exercise, stretching, yoga, meditation, scheduled breaks, and nutrition to reduce psychic and physical stress and strengthen the body at its seams. These conditions -- as well as many others such as chronic back pain -- can also be alleviated this way. These are not permanent conditions in many cases although Western medicine often finds no financial incentive in treating them properly.
Anyway, Greenspun seems to have great insight and sensitivity regarding his employees. He will surely put a program in place to prevent stress from harming his crew and his company. Afterall, he has more to lose than anybody if his workers are not healthy and his company folds. I believe it is merciful to dismiss the average programmers who can't keep up before they break down under the pressure. I believe it would be wise to tear the exceptional ones away from their computers for a game of basketball on company time, deadlines be damned.
Overall, aD is probably a great workplace for exceptional people and a terrible place for average ones. This is the best kind of new economy company.
-- Alec Permison, November 6, 2000
Sounds like a well appointed sweatshop to me.
If this is the way you run your company, I'd guess you should be expecting your first employee suicide within the year, if it has not happened already.
Of all the companies I've worked for over the last 17 years, mostly in the Bay Area, those that have come closest to the environment you've described are the only one I know that had employees commit suicide due to burn out. In all three cases they were kids fresh out of college and who had no other work experience to give them a perspective on how well managed companies do not burn out their employees with 70+ hour weeks, week in week out. They did not have a life outside the company so they had nothing to fall back on when the company made unreasonable demands on their time and thereby,literally,worked them to death.
What you describe is not a employer but a very sophisticated form of cult.
When I see companies working long hours for long periods of time I see burn outs producing substandard and ill designed code. Boasting about long work hours is nothing more than a very juvenile form of geek machismo. And like all forms of machismo it can kill or maim those who are seduced it.
If you want a long and productive programming career you have to have a full and active life outside your work, and only work for people who make reasonable demands on your time.
joseph mc connell
-- joseph mc connell, November 6, 2000
I have to second the comments on long hours. While it can easily be argued that it is more profitable and faster to have your programmers put in 80 hour weeks, it is not necessarily to everyones benefit. If you pay a programmer a salary of $100,000 then you are paying him or her at the rate of $50/hour which you can bill to the project. If you convince that same programmer to work 80 hour weeks, then you are paying the programmer at the lower rate of $25/hour and putting $25 an hour into extra profits because you are still charging $50/hour. From an investment perspective, a salaried programmer, putting in long hours offers very poor returns. The principle of "fair exchange" says you should compensate that programmer for investing their spare time in the company. More importantly, as has been pointed out, the cost in personal terms of 80 hour weeks on famlies and relationships is brutal. There is no point in pursuing "worthwhile" projects while harming peoples lives.. kind of a contradiction. One can bring a bit of reality in and schedule a project based on 40 hour weeks.. after all getting to market a month earlier hasn't proved much in the dot.com work other than you can run out of money faster. If one wishes to invest their spare time in work because they are young and single, thats fine, but if they invest their time in their children or spouses or communities, then that should be fine as well. Projects should not be scheduled based on absurd requirements on people.
-- James Ross, November 6, 2000
I'd like to point out a very bad global effect of the current 70+ hour/week workplace, which goes hand in hand with software engineers becoming largely unemployable by age 40 plus or minus:
Where will companies find workers when this brutal reality seeps down to the high school/early college level? Won't most good people, the ones who don't have a real calling to software they can't ignore, avoid getting into the field?
-- Harold Ancell, November 6, 2000
I think a lot of the people opining and singing threnody about the victims of the long and difficult work week are ignoring several of Phil's points, specifically:
Programmer's should feel comfortable having friends and family at the office
The office should provide many more interesting things to do besides work (he gave a nice list)
The office should be more pleasant than the average programmer's home
As a full-time developer in a company that has made half-hearted attempts at these things I can tell you that working 60-65 hours a week comes naturally. I enjoy my work, I'm challenged by those I work with (indirectly), and I can see a direct result between my achievments and the success of my company.
The point here is that Phil is not advocating the sweat shop (quite the opposite - see the Japanese code factory reference); he is advocating a work environment not unlike those that existed two centuries ago. Then you played, loved, learned, and taught in the same place where you made your living.
I will go a step further than Phil and prognosticate that the most productive companies of the future will be entire communities (real not virtual). Of course I'm not the first to think this, but the point is worth recognizing.
As an aside, why is it that we don't recognize that sports superstars put in tons of hours every week to reach their success? If we treated our best programmers like superstars, maybe they would start acting like them.
-- Christopher Atkins, November 6, 2000
It seems to me what Phil is presenting is merely a recipe for economic exploitation rather than management of people. In this world there is no true acceptable bargain other than one that leaves both parties winners. What Phil is presenting is a model that maximizes his gain at the cost of all quality of life for the people he is managing. That model cannot be sustainable. Companies that rely on this sort of management must and will eventually collapse in competition with organizations that treat their employees like people rather than units of productive capacity.
-- eric larson, November 6, 2000
The concerns people express about long hours are quite valid, but I do not believe they are necessarily at odds with the intent of the article. The '70-hour week' is quoted in a fairly simple example, I doubt that is really meant to be an indication of the real hours worked at aD. The example was meant to illustrate the effect of management overhead (Brooks' Mythical Man Month.)
Furthermore, there is much to be said for working intensely on a project so long as there is a commensurate 'downtime' (one of the reasons I quite enjoy project work).
Finally, there is a huge distinction to be made between the sickening sense of obligation to stick around at work as disaster looms and management guilt trips you and hanging around work because you are excited and feel like you are doing something useful and productive. If I get rewarded for the work I do and I like doing it I can make sensible decisions about going out with my friends or working. That is way different to unrewarded looming deadlines.
-- Jeremy Nelson, November 6, 2000
I think what _every_ respondent failed to see is that Phil's 70+ hour week does not mean 52 weeks at 70+ hours a week each year for 40 years, rather that when a project needs it, the programmer does not ask how many hours they've worked at all -- solve the problem now, let the time work itself out. Another aspect that most fail to acknowledge is that programming is not an 'at will' activity such as flipping a hamburger.
A good coder refuses to write bad code; if their mind is not conditioned at a moment to write good code, they'll not write code. IMHO, Phil's approach respects this _feature_ of quality coders/engineers that traditional management fails to accomodate.
-- brent verner, November 6, 2000
There is a lot of good sense and a lot to learn from in this article. However, there's also a lot to dispute. Comment #1:
Suppose we managers at Ars Digita, presumably an example of the point of view in this article, were given an opportunity to hire a guy named Phil Greenspun. He's certainly very smart, experienced in our kind of project, productive, maybe fantastically so, and a terrific communicator, but is he going to give us the hours? He wants to teach a couple of classes at MIT -- that'll probably cost some time. Maybe he can hold them in the comfortable environment of the office -- a good place to bring friends is probably a good place to bring students -- and maybe he can provoke some intense discussions among them so he can write some code while the students learn productively amongst themselves. This guy also likes to travel and take photos, and write extensively about them. Do you suppose he could take pictures of the visiting dogs fighting over pizza scraps in the playroom, or may snap a few shots from the windows of the ocean-view retreat when it's his group's turn to go there?
Not only Greenspun, but other highly qualified and productive people like and need to have pursuits outside the office, benefiting the world at large, their families, and/or themselves. Often, it would be a mistake to reject those people because they're not willing to give up those pursuits to work in a dotcom environment. If having a database-backed website is so urgent all of a sudden, maybe there's been a slipup in the planning stage. If it has to be designed by no more than two people maybe those two people should be given a reasonable deadline, or should agree to crunch hard for awhile in exchange for time off for the photography trip to Italy later, or should receive more than their normal salary so they can make more of their vacations.
Comment #2: Management guides of all sorts are filled with bogus calculations, and this one is no exception. The maxim that 55 hours is twice as productive as 40 depends upon the assumptions that 25 hours is 'wasted' in coordination of effort, and the remaining 15 hours of the first 40 are all useful work. Why should 25 hours of coordination be necessary in a 40-hour week? Maybe 10 would be enough, and worth striving for. But if only 10 hours were 'wasted' in coordination, it would be necessary to work 70 hours to be twice as productive as you would in 40 (but of course the 40 hours would be twice as productive as Ars Digita's 40 hours!) Or maybe 4 hours out of the non-coordination hours are devoted to surfing the web and slashdot (less than 1 hour per day). If you're trying to do twice as much productive work, you don't necessarily need to double the surfing activities, so simply subtracting off the coordination time and doubling what remains isn't right either.
Comment #3: It makes perfect sense that using time at the office for activities marginal or irrelevant to the current projects should not 'count' as productive activity. If I spend an hour every day on the climbing wall, I ought not to go home for the weekend with only 40 hours spent in the office. But if I'd rather spend that hour a day somewhere else, like walking on the beach, and spend my time at the office in more concentrated work, why should this be a black mark. What counts is the productive hours and the results. If the company wants to make it convenient to have leisure and exercise and relaxation in the office environment, fine, but the guy who wants to go home to read his kids a bedtime story, go to a chamber music concert, or even develop a new algorithm for predicting protein folding, might be getting his project done just as well as the guy who's dangling from that nubbin on the climbing wall.
Comment #4: When I referred my wife to this article, she had several comments: -- Vis-a-vis adding dogs, pianos and climbing walls to the programming environment, how about conjugal visits? -- Is this material absolutely serious? ... There are plenty of reaons for adding amenities to a sleep- and exercise-deprived workstyle in which the company has much to gain from long hours and enhanced loyalties. But, I mean, is this Machiavelli? (And was Machiavelli even totally serious?)
-- Jeff Greif, November 6, 2000
There's nothing unhealthy about longer hours if the programmer knows that 40 hours is acceptable and the extra hours are a free choice. Programming is my hobby as well as my career. If work is fun and the workplace is pleasant, I will choose to work more and it will be no different than going home to concentrate on some other hobby. I also have an S.O. and a life, so I will never work for a company which expects me to work more than 40 hours a week.
-- Chris Newman, November 6, 2000
I can see that I struck a chord with the "70-hour" thing... I don't think I got my intent across clearly. Certainly my personal goal is not to see the programmers of the world work 70-hour weeks for 45 years each and then get a gold watch upon retirement. At the same time, if one of my students came back to me four years after graduating from MIT and said "my career pays adequately but it doesn't inspire me and I watch the clock to make sure that I am out the door at 5:01", I'd be a little bit sad. I'd be happy if my student became an inspired watercolor painter, an inspird environmental activist, an inspired fiction author, an inspired cabinetmaker, maybe even an inspired campaigner for George W. Bush (how's that for extreme). As long as he or she were inspired enough by something to give every ounce of energy and effort. Would I expect that level of effort to be kept up for 45 years? For some exceptionally creative people, sure. A lot of Nobel Prize-winning faculty at MIT still work pretty darn hard though they have their tenure and their fame. For others I'd expect them to go through cycles where relaxation, travel, and family become more important. There would be no shame in working for a few years to build something great (be it a software product, reputation as an artist, non-profit org) and then doing something a bit different and less intense for a few years.
(Oh yes, and for the folks who've mentioned RSI... Microsoft Natural Keyboard. It is the only answer!)
-- Philip Greenspun, November 6, 2000
I think the point about learning to work accurately and quickly is a good one. But working at a rapid pace should only happen some of the time, like when you are making a major design change. Also if you work really hard for 9 hours in a day, you are beat and had better go home. There is a contradiction between working quickly and working long hours. If you do both its unlikely you're working smart.
-- scott Plumbleg, November 6, 2000
I noticed that family life is one element that is missing from this description of a professional software programmer. I am a software architect with an internet-related company. I am living a leading-edge professional career with a professional spouse and kids. According to this article, it seems that my life should not exist, or I should feel guilty about living it because I am not in the office long hours during the week or during the weekend.
Answers to these questions would help my understanding:
Can I expect to be an innovative programmer, and still have a family?
Where does balancing my work as an innovative programmer with that of my professional spouse's work fit in?
Where do cub scout meetings, camping, playing soccer, etc. fit into a successful programmer's work week?
Scott McConnell addresses this issue in his book "Debugging the Development Process". He managed the Microsoft Excel project through multiple releases. At one point in his book, he addresses the long work week issue. He says that anyone who works long hours for any length of time ends up taking long lunch breaks, performing errands from the office, and other tasks to catch up with daily life. The net actual work performed is on the order of 30-40 hours per week.
-- James Violette, November 7, 2000
Mr. McGregor's (much earlier) comment on the difference between "punishment" and "negative reinforcement" is flawed.
Negative reinforcement *is* punishment. If I have my toys taken from me for writing bad code, I get mad about my toys. Morale goes down. My code stays bad. If I get flogged continuously while writing bad code, I become upset at being flogged. Morale goes down. My code stays bad.
After all, even if I get my toys back or the flogging stopped, my environment has not significantly improved from its base condition. I signed up knowing that I get toys and that flogging is illegal in a work environment. Most companies I could work for are likely to take away toys on a whim, or start flogging should it become legal. Either way, such an act brings my environment closer to or below the base condition.
Adding toys I want (as opposed to toys in general) or having people I hate get flogged would be something I'd work harder to get. I'd work harder if I knew that repetitive, redundant paperwork would go away. I'd work harder if I knew that I would be paid better *at the end of this project phase* and not sometime in the far future. I'd work better (not just harder) knowing that others would enjoy my code (train me to write code worth enjoying).
I can endure suffering. But I cannot work well while straining my endurance. Seventy-hour weeks? Sure. Give me enormous benefits. Forty hour weeks? Sure. Make sure I'm in an environment that lets me work to my best capacity. In fact, I want that environment for the seventy-hour weeks, too.
And that's all I have to say about that.
-- Zach Collins, November 7, 2000
I think I have to agree with most of the comments about long hours and such. I am currently a junior computer science major at Texas A&M University, and I have had 2 internships, and a research grant (at TAMU). My experience so far has been that I like to work longer than 8 hours when I don't really have anything else better to do, but 70+ hours wouldn't be good. MAYBE 55. As a young single guy who loves computers and technology and electronics and math, etc., I like to accomplish things at work. However, I also like to go back to my place and learn new stuff, so I can accomplish more. If I don't get home until 7-8 pm, I don't really have adequate time to spend with my family or friends, or doing anything that I love to do outside of work. That kind of thing would just make me resent my job, and look for another one. And remember: all this from the perspective of a guy who the author says would be happy to work 70+ hours.
-- Ben Collins, November 7, 2000
The best way to alienate women from IT is to continue spreading this myth about the 70 hour weeks. The only people who truly believe that they produce better results by working more are people that
don't have a life away from the machine
aren't able to judge the quality of their own work
Women don't usually fall into either of these categories! Women generally have a much more balanced life, understand the need to do basic things in life, i.e. grocery shopping, cooking, dishes, hanging out with friends, hobbies and yes, raising their kids.
The funny thing about a balanced lifestyle is that although one works less, the work one does is better. And because one is able to go home in the evening (at 6:00!), one has time to reflect upon the work that one has done with some perspective. And consider what goals one has for the next day. And if the programming from that day was worth anything.
I suspect that the reason that I encounter so much buggy, lame code in the ACS is that the code was developed exactly the way you are suggesting in your article.
-- Sarah Arnold, November 7, 2000
This article is seriously flawed.
Written in a goading style, it ignores much of the ongoing research into software productivity, (See Capers Jones, Barry Boehm, Steve Mc Connell, et al.). The recurring truth is that in successful software projects, a mere 20% of the effort is spent in coding. This article pretends that coding is the only thing that matters.
This is very flattering to those who code, but ignores reality. Coders may read this and say, "Yeah, finally someone is speaking for us!" But anyone who has occasionally looked up from the monitor to take a look around the rest of the office knows that this view is extremely myopic. Programmers aren't the only people in the organization. And any software company that cannot make use of the average programmer while slavishly worshiping and abetting the whims of the often overrated and inconsistent superstar is bound to fail in the long run. The superstar will sometimes do something brilliant that saves everyone's ass. But planning for this, and staking the company on such erratic behavior is just plain stupid.
Rather, the key to consistent (rather than haphazard) software success is planning, coordination, communication, and perseverance. To suggest otherwise is special pleading and vanity of the sort that leads to hubris. And the gods always punish hubris.
Fred Williams
-- Fred Williams, November 7, 2000
I see a lot of complaining about the 70+ hour work week issue. I think most of the people here miss the point of what "great" programmer means. You can be one of the best writers in the world but if you write only a paragraph a day you'll never be "great". You may technically be one of the best artists of your era but if you don't immerse yourself in it day and night you'll never be "great".
Sorry, you may be a genius problem solver and coder but part of being a "great" is giving yourself over to the art. It DOES mean giving up your free time, it DOES mean maybe not having children, it DOES mean maybe burning out, it DOES mean sleepless nights telnet'ing in from home to work on the problem you just left. Being a programmer at the "great" level, building a major system with the purity of vision you need to be "great" means no distractions and getting the core of the code down before the "Man(ager) from Porlock" comes along to snatch your vision away.
Putting it more succintly, arsdigita gratia artdigitas =)
-- Mark Mills, November 7, 2000
Many of my comments have already been said. I would also suggest to Phil that his RSI suggestion is much too flip. Sure, Microsoft natural keyboard. But even there people with serious RSI have problems.
But that's relatively minor. I think that you should take a look at the research into brain physiology and how that relates to attention and time spent on tasks. If you consult with people in neurophysiology and look around you will find out that the kind of hyper stimulation that you are suggesting leads to brain damage. It causes shrinkage of the brain tissues that deal with the correlation of data when prolonged. One can meet these people, the veterans of startups and places like the Redmond offices of Microsoft. They are the ones who know a great deal, but can no longer respond with the answer quickly. Many can hardly function at all without copious amounts of coffee.
My personal observation is that I think that such behavior when prolonged leads to other kinds of neurophysiological damage as well. I think that further research will document this. The behavior I am referring to is that of spending too much time concentrated on one task. Lack of sleep also contributes, as does levels of adrenalin. When coupled with the commonly poor nutrition of the "programmer lifestyle" you describe, all of this causes serious problems over time.
There is also the research of a neurologist at, I believe it is Harvard Medical School, though I may be mistaken, into the reasons for the greater shrinkage of the frontal lobes in males versus females by the time middle age is reached. He believes that this is related to the fact that males tend to use the same areas of the brain when in relaxation as they do when they are working. Whereas females show a slowing of metabolism in the frontal lobes when they are asked to relax. He is studying the 10% of the male population that does not experience frontal lobe shrinkage by the age of 50. (By the age of 50 most men have smaller frontal lobes than most women.)
Please note that the lifestyle and management methods you are advocating is, according to research, pretty much guaranteed to cause brain damage, and quite rapidly - just a matter of 5 years or so before significant effects can be measured. I am not being facetious here, it is quite a serious matter.
-- Brian Hanley, November 7, 2000
It's interesting that most of the people here appear to be US based.
As someone that now lives in regional Australia, But has spent most of my professional life developing software in New Zealand many of Phils ideas sound lovely but are unobtainable in these smaller economies.
A office decked out with playrooms, beanbags, Air Hockey etc would be great but outside of a dot com heaven like Boston or Silicon Valley it just is not going to happen.
Mine is a case in point, I'm working on a package for ACS 4.0 to help with News Media publishing (I'm a developer for a newspaper), I'm also the IT Manager, so yep I get to pull the 70+ hour weeks.
What I do have is the ability to go grab my dog and tube down the river at lunchtime if I want or jump on my ducati and go for a fang through the hills.
The message in Phils article is to treat good programmers like you would any artisan, accept they will have their idiosyncracies and provide an environment that allows that. Their own ego will discipline them into giving you a good return on your investment.
Sticking them on a 9-5 in Cubicle hell will just take the joy out of the art and you'll get crap code.
So do I provide people anything else other than a good screen comfortable office, no I don't. But if they want to start work at 2 in the morning (I don't care) they spend half the day surfing slashdot or reading Code Complete or trying a new language (I don't care). If I only loosly monitor these people I'll get far more out of them than if I MANAGE them.
Now if only I could bring my dog into the office, that would be cool, although a labrador that likes to chew could do serious damage to the fibre comms cabinet :)
Maybe when I've finished newsflow (the News Story ACS4 package) Arsdigita will open a office in Australia or NZ and I'll ship off my resume, until then the dog stays at home :(
-- Roger Lockerbie, November 7, 2000
from
http://www.cultinformation.org.uk/faq.html#cult
My comments in [].
What is a Cult?
Every cult can be defined as a group having all of the following five characteristics: 1. It uses psychological coercion to recruit, indoctrinate and retain its members
[for example trying to convince the 'employees' never to go home by making the office nicer than home, indirectly forbids contact with non company employees by keeping them in the office during all potentially social events, holidays outside work discouraged.]
2. It forms an elitist totalitarian society. [average people will face rejection at the whim of the employer, possibly being taken aside for special care to make them a good progammer.]
3. Its founder leader is self-appointed, dogmatic, messianic, not accountable and has charisma. [the founder is not accountable and self appointed.]
4. It believes 'the end justifies the means' in order to solicit funds recruit people. [each person that leaves a 6pm should be found a project to *make* them stay. Pay is increased, goodies are given away to encourage them to stay for as long as possible. No asking if they *want* to stay. ]
5. Its wealth does not benefit its members or society. [since they don't have a chance of ever getting to spend it]
All in all, Greenspuns 'ideal office' probably isn't a cult. However, it's far far too close to one to make me submit to brain washing. Sorry, I mean work for him.
-- Pete Stevens, November 7, 2000
PG writes: "Oh yes, and for the folks who've mentioned RSI... Microsoft Natural Keyboard. It is the only answer!"
Not only is that not "the only answer", suggesting that there is such an "answer" to RSI is a gross oversimplification of the problem.
Suggested reading: http://www.amazon.com/exec/obidos/ASIN/0471595330/
-- John Siracusa, November 7, 2000
1. I disagree that an outstanding programmer is 10 times as productive as a good programmer. In my experience it is more like 16 times as productive.
2. As far as people having an inflated idea as to their value ... I just completed a round of interviewing Senior DBA candidates. It was a frustrating experience since all but one were barely qualified to be a junior DBA. For example, one candidate who demonstrated a complete lack of understanding concepts is currently making 85K. This person was out looking for a job because his present position doesn't pay enough :-(
3. As far as long hours go ... I think one responsibility of management is to go in and chase the developers out of the place at least once a week in order to protect them from burnout. Truly outstanding programmers (and engineers) are self-motivated and if they are interested minor things like working hours, good eating habits, clothing changes, and bathing tend to get lost in the shuffle.
4. Open offices can be great! One project I worked on had four developers sharing a 30 x 30 space. We each had a desk facing a wall and in the middle we had a table. This gave us the privacy we needed when doing individual work while it greatly simplified communication.
-- Jerry Gitomer, November 7, 2000
In my experience, someone who needs to work their staff 70 hours a week is a bad manager.
Probably never heard of contingency, planning, resourcing, staff turnover, empathy or respect.
-- John Smith, November 7, 2000
I am glad to see the issue of overwork being brought out. While I agree that having a good work environment that caters to programmers is good for everyone, the motive to use programmers as a means to extract extra profits is dubious. As I mentioned before, a salary means you are paid for 2000 hours a year more or less, not 4000 hours. Independent contractors know this and bill for every hour, but salaried employees who put in 70 hour weeks to build a commercial website are just fooling themselves. I worked in the aerospace industry on critical projects during the Cold War in 70s and 80s and we rarely put in more than 50 hours/week except in emergencies and that was a lot more worthwhile than a Sales Intranet site. Philip said that the goal is to produce more Richard Stallman's etc which is admirable. I have noticed that most of these huge contributers to CS had day jobs which did not demand more than 40 hours so that they could spend their spare time working on concepts and software (mostly at universities where they also had free access to computing resources). Like many engineers I probably spend 70 hours a week at least on my profession and have invested in significant computer systems, however only 40-50 hours are directly related to my job. The other hours are spend playing, exploring, reading, coding etc as I see fit. This is where I learn new things and explore new ideas that I can put to use in the future. As an example of the foolishness of working long hours without compensation, friends of mine worked at a dot.com which seemed very solid and repeatedly put in long weeks and weekends etc to meet arbitrary deadlines and were encouraged much as Philip suggested. The investors then decided to change direction and most of the staff were laid off without warning. The management of course managed to retain their jobs and snag huge bonuses
-- James Ross, November 7, 2000
Web site development doesn't require quality because it produces disposable software. Web applications written today will be trashed next year. This article is consistent with achieving rapid deployment of temporary (i.e. no need to worry about maintenance) software.
I have never met a software wizard ('productive programmer' in the article's terms) who could produce quality, long lasting software. Thats why it doesn't matter that the web world is dominated by productive programmers. Not for now, anyway.
The best software I have encountered has been produced by dedicated people who go home at 5:30 and start work the next day revitalised.
I have worked in Cambridge MA alongside ex MIT 80 hour weekers and I have worked in Europe alongside 40 hour weekers. The productivity was about the same.
I would like to hear from organisations that develop software products with a lifespan of more than two years. Is the programmer the important element? I think not. They are just the factory floor workers adding in their valuable piece. The team makes a quality product. Designers design, analysts analyse, managers manage and sales and marketing people make it successful.
-- Neil Burnett, November 7, 2000
It seems everyone responding is in the class of people beyond "just graduated". I recently graduated from a four year university and am currently working at a dotcom company. For me, I see it as an alternative to school. It allows me to push myself harder, learn faster, and get a jump on my financial future. Most importantly, the work is more rewarding and I deal with more intelligent people.
The article is aimed at managing startup companies. It's not for managing people who work at the large software companies. Startups generally don't have their own day care centers, gyms, pools, etc. A startup only works if you don't carry any extra baggage(i.e. people looking for a free ride). People working startups don't want those things (avoid them, actually). They work for one or more of the following reasons: money, inspiration, education, and freedom(yes, freedom). Freedom meaning nobody tracks your time, just your work. If you leave at 2 in the afternoon and come back at 11pm, it's up to you. A person working at a large company is there for: job security, retirement, benefits, and a paycheck. The goals are quite different.
Work is my entire life. Would my life be better spent if I joined a frat and drank myself to oblivion every weekend...I doubt it. We're purists: the type of people that think G. W. Bush's DUI makes all the difference in the world. For someone to be great at something, it is their life...no more, no less. His DUI tells me being president has not been his life's goal.
Jeremy H.
-- Jeremy Hughes, November 7, 2000
The key is finding the right sort of people to work this scheme with. Programmers/Hackers work in bursts. When there's an interesting or challenging problem, they are willing to work those insane hours putting the whole thing together. It's fun to spend two weeks holed up in the office with friends, working on a big, cool solution to a neat problem. This is not sustainable though in general. Eventually, everyone (even hackers) needs some downtime. The only way it can work is if you can find the kind of people who will competely forge their own social group around their co-workers. Then work is their social life, and they can work those 100 hour weeks without quality of life suffering. Depending on having that kind of person, while trying to grow your company past 40-50 people who share the same vision is the real trick.
-- Rob Meyer, November 7, 2000
Jeremy Hughes' comments are spot on. The practices and principles in this article may apply to start up companies and dot coms but are very difficult to apply once a company moves beyond this point. What start up companies and dot coms have in common are relatively simple products. Once a product matures and its customer base broadens what a product manager needs is those who can create the right product, in the right way that will meet customer expectations. This requires know-how and experience. Far more than a gun programmer that will work 80 hours a week to meet a deadline, the product manager needs an experienced software engineer who understands the market, good design, risk management and mentoring of others. This person is usually not in their twenties, wants a life outside of work and is willing to hang in there for the longer term.
-- Craig Ashley, November 7, 2000
Excellant article with an inaccurate title. More correct is "Managing a Software Sweatshop." And what's wrong with working in a sweatshop? It robs you of your humanity and you become a disfunctional member of society. Your personal relationships, if you have any, breakdown. You do not contribute time to your child's school or extra-curricular activities. You do not contribute to your church's work -- you might not even go to church. And all this distortion of the employee's personal life is to make the business owner and his inner-circle very rich. It's actually a great experience for a short while, but it is unhealthy for people in the long run.
-- Robert Canright, November 8, 2000
You know, if Greenspun here is really serious about wanting to get programmers to work these really long hours and if he is honest about how much it improves the profitability of a company, then I wonder why he doesn't pay by the hour. The most direct way to reward someone for the hours they put in is to pay them for each and every hour they put in. Freshman econ kinda stuff there. You pay them a competitive wage at 40 hours per week, and then every hour over that, they get the same rate at time and a half overtime, as the law requires. If it is so massively profitable to have programmers work those hours, there should be PLENTY of cash to pay the programmers for working those hours, right? So the more they work, the more money they make. If instead, the management is trying to get rich on the backs of the employees, they'd pay a flat rate and then try to work the employees as much as possible. Why should those extra hours be free? You want it, you have to pay a premium. I'd even argue that there should be an increasing scale, so hours over 60, for instance, should perhaps be paid double, then hours over 80 are paid 2.5, and so on for every 20 hours more in a week. That extra time is extremely stressful and hard on one's outside life, and so the cost goes up. My personal belief is that if Greenspun DOESN'T do something like this, then his whole article is BS because he's not backing up his rhetoric with his money.
-- D Goodkin, November 9, 2000
Remember folks, this article is about how to put out products cheaply and in the shortest time possible (which usually go hand-in-hand but not always) to make the most money for the company. That's why "Managing" is in the title. It is not about how to create the highest quality products. It is not about how to retain employees. It is just about making money. In certain fields of programming this is a viable solution for the short-term. Trying to pass it off as "for your own good" is just the rhetoric-spin that people always use when trying to get you to do something that is not in your best interests.
-- Jeffrey Kabbe, November 9, 2000
Is there anything wrong with working circa 70hpw? That's probably a bit more than I do (yes, I have a family). However, I'm not sure about trying to *code* for that kind of length of time. If you can code for even an afternoon a day then you're productive. I'll let you figure what an afternoon is.
I do think it's a mistake to measure hours: that's just an accounting convenience to determine client billables. Billable hours are a largely sensible business practice, because they're easy to pad and have the seeming forms of accountability and professionality. Closed source used to be a largely sensible business practice as well.
There's a difference between billing hours and getting things done (but we all know that). Hence I disagree with another poster who said that ArsDigita should pay by the hour. Since being paid by the Things Got Done maybe difficult to implement in a general way, a salary seems a reasonable compromise. But in terms of evaluating your ability to work *hpw are shockingly useless and almost certainly misleading. What does the fact you've worked 90 hours this week state about what you accomplished? What does ArsDigita's mission statement mean in terms of hpw? As computer scientists like to say, these things are orthogonal.
Anyway, all you really need to know is how much you got done last week/month/year. Since that's roughly how much you'll get done next week/month/year. If you're not happy with that amount of got done, then you need reflect on your life in order to change things.
Also, I'm surprised at no mention of Extreme Programming so far. It's supposed to be controversial, so if you liked this page you'll probably like this book: Extreme Programming Explained (also a good of example of a book that is no longer than it should be).
-- Bill de hOra, November 12, 2000
Oh yeah, some responses:
Remember what Fred Brooks said in The Mythical Man-Month: high quality systems must be architected by no more than two people.
-Don't architect your systems. Fred Brooks was right a long time ago, not now. Software systems that are used are never finished: therefor static architecture of software is a mistake. Don't bother designing at all.
Your business success will depend on the extent to which programmers essentially live at your office.
-You're confusing physical and mental presence.
How does one create a good programmer?
Make her work with a great programmer.
What attracts good programmers? Traditionally the best programmers seek the most challenging problems. They want to work in an organization that is trying to build something important.
-They also want to work with minimal interference. Let programmers program.
If you see one of your best people walking out the door at 6:00 pm, try to think why you haven't challenged that person with an interesting project. If you see one of your average programmers walking out the door at 6:00 pm, recognize that this person is not developing into a good programmer.
-Early birds aren't good programmers?
Yet managers who are spending a portion of their time designing software or writing documentation are at risk of neglecting their duties to review subordinates' work.
-don't document and don't design. Also, conserve managers.
Our solution is to decouple responsibility for review from responsibility for scheduling review. We use administrative assistants to ensure that each manager is scheduled to look at every subordinate's work at least once per week, more frequently in the case of junior employees.
-if reviewing is good, constantly review. Use programmers to review programmers.
Software engineering companies will tend to have a fairly flat distribution of intelligence. The 22-year-old Stanford CS punk that was just hired will be just as smart as the 30-year-old lead engineer who will be just as smart as the 40-year-old CEO. Within a company's technical team, the raw IQ differences are even smaller.
-if we know that there is a least 10-1 difference between great coders and everyone else, then we know that IQ has little to do with it.
positive reinforcement is more effective than negative reinforcement
does not easily sit with:
But at the end of the day nobody should be confused as to who is providing leadership. There is an irreducible amount of Engineer A imposing his or her design on Engineer B. This can lead to some harsh-sounding words and bruised feelings.
-In discussing the workplace, you neglect to mention psychological comfort.
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. -then: learn half as much new technology (if technology moves so fast, half of it won't be worth learning anyway), halve coordination with other programmers, halve documentation time, halve leadership activity time, halve attempts made to comprehend complex systems. Under this reduction a programmer working a 40hr week will be almost twice as productive as one who doesn't. Under this reduction a person who works a 55hr week will be roughly 50% as productive again as one who works a 40hr week. One will actually need to work just under a 70hr week to be twice as productive as someone who halfs their non-code activities. It's obviously more efficient to perform a self-motivated business process reengineerment than double time spent coding.
-- Bill de hOra, November 12, 2000
Programmers dread elaborate process, endless meetings, and layers of marketing approval before a product can be shipped. Ideally it would be possible to conceive a product on Friday evening, set up the development environment Friday night, write code on Saturday and Sunday, test on Sunday night, and ship on Monday morning.
An excellent article that generated a lot of discussion about productivity, work hours and defining "great programmers". However I was shocked to see this gem pass everyone by. In the above scenario even cutting edge companies with great programmers are going to be shipping crap out the door because they neglected to put the hours in testing it.
-- Mark Pawson, November 14, 2000
It's amazing so many people criticizing the 70 or 80 work week.
You will probably work for 10 or 20 hrs doing something that is very very boring to you, as a programmer it might be : debugging a script you didn't write, sitting at a weekly meeting , answering email , or anything else you may find annoying .
And the way I see it , the other +50 +80 hrs has to be spent doing something that REALLY REALLY appeals to YOU , if it doesn't, the 70-80 hour work weeks will seem like a living hell.
In company or corporation terms, it doesn't matter how good the culture or spiel is, it may offer you whatever benefits,money,work environment,growth, or even the CHAIRS THEY USE ! in the end if your in it for the: I am working at X company and WE are developing blah,blah,stock options...
Notice the WE, I think there is a special distinction in the WE..... The extremly common BANDWAGON TEAM WORK environment: WE are working in a gizillion dollar project, WE are developing a HOT new java API.
The difference is that the company really doesn't gives a rat's a** in the end, they want you to get the work done!. If YOU REALLY dont like it, you will not only stick out the typical 10-20 hrs doing the annoying work,your whole 70-80 hours will be the same, your 30 minutes of glory will be when you brag to non-coworkers the HOT new API or stock-option's.
The people who are working the 70-80 hr weeks probably do believe in their job, the "team work (smart people attract smart people)" and "work environment (beach houses, ski houses ) " are all major benefits. But in the end , they must posses a "self-interest" in what they are doing. When the dust settles and you see the 90 grueling hours, wise-a** managers, no 5 week vacations , where will you be left ?. I wonder how much time the REAL employees spend at the ski-houses, beach-houses or whatever fun place. I wouldn't doubt if these things had a sign saying: "FOR EXCLUSIVE USE OF POTENTIAL HIRES"
My brief experience.
I read this spiel , excellent, "Home Study Program" , $10,000 signing bonus!! thats for me I said.
My friends: your crazy!, 2 months working for free ! . my naivite on the $10,000 bonus blinded me at the moment, but I knew it would be worth it.... so 2 months passed, and I turned in the problem sets:
Answer : We have a hold on hiring at the moment, please check back in October.
My sub-conscious: I knew it , my friends where right !!.
But wait, its a great system. My self-interest or possibly "naivite" pushed me to do more, lets learn Oracle from the ground up lets go for Oracle Certification, lets do something radical (may be even stupid) with AOLServer an AOLServer Driver with JDBC , for sure the Arsdigita guys will like this, BUT lets keep a backup project just in case , you never know!.
Sure enough this October came, with all the hard work I thought I was a shoo-in:
Answer : mmmmmmmmhhhhhhhhh,we are looking for project managers and QA engineers at this moment.
Great, just great, 6 months down the pipe, right ? WRONG!
From the beginning I (sort of!) acknowledged that if it didn't turn out , what I was learning would pay off.
Am I mad because Arsdigita gave me the cold shoulder ?
I am greatful with Arsdigita for offering such a system for FREE, for the cold-shoulder ? , its what I could have expected from any company be it Sun,Sapient or whatever other company out there.....
Remember that a companies work is to TAP (exploit!) its workforce knowledge,they know some guy is possibly worth $150,000 a year , and another $250,000 a year, they MANAGE THE PROGRAMMERS so they will be worth $600,000.
They reap the benfits two ways : From the $600,000, they pay the employees a little less than their worth say $80,000 (vs. the $150,000 ) and $120,000 (vs. the $250,000), and MANAGE the chemistry (a.k.a. "added value"), total net gain for the company: $230,000 (yes, the $200,000 not accounted for goes to the MANAGER and $100,000 for your Insurance,Skihouses,and pinball machines).
Is there a problem ? Absolutly not, as a matter of fact its perfect , everyone is happy !.
Just as a final remark, when you do your job try to focus "inwards" on your SKILLS. Uncertainty is the only certainty ! , and your skills are probably the only CONSTANT you have.
As someone mentioned in a previous post, "independant consultants know what they are worth, they charge by the hour"....but until the time comes when everyone of us knows "what they are worth", companies will still be TAPPING (exploiting!) away and MANAGING PROGRAMMERS.
-- Daniel Rubio, November 18, 2000
Phil mentions (and links to) a study that shows how people are unaware of their own incompetance. I would add what I feel is an important corrolary to this: that people highly competent in one field are often totally incompetent in a different field, but think that they are "smart" and therefore competent in the other field as well. For example, Bill Gates is a world class expert at getting rich, but he's totally incompetent in the area of diet and exercise, as evidenced by the pot-belly he displayed on the cover of a recent issue of Business Week. However, if you were to ask Bill about it, I bet he would think he's very competent. I think so because he invests in biotech companies, and he could tell you a lot about genetically modified food and whatnot (he wrote an article about GM foods for Time magazine).
Another point related to this: you should never trust a person's self-assesment of any skill in a job interview!
How many times do people ask, "How would you rate your C++ skill" (or whatever) in job interviews? Don't ask questions like this. The answers are completely useless, as both the competent and incompetent will give the same answers. We routinely find that people interviewing for programming jobs lack the skills they claim to have on their resumes. We can expose this by asking them to write the code to solve a problem that lies entirely within the domain that they claim to understand. Something like "query the database for a list of names, and generate the HTML to put it in a listbox." If the applicant claims to understand both the database and web programming technology, they should be able to do this. It's amazing how many people can't.
-- Wayne Radinsky, November 23, 2000
> If a product is being developed rapidly
I think you misspelled
"If a project is poorly planned and badly executed"
Hope this helps.
Sean.
p.s. Any project where "average" programmers are having to spend "nearly their entire work day reading and understanding new code" is in serious trouble.
-- Sean Sollé, November 23, 2000
Everyone's covered the long hours thing except that I wanted to add, since project planning is rough and surprises do happen, even planning on the basis of 40-45 hour weeks is a bad idea. I suggest that projects should be planned and scheduled on the assumption of 30 hours/week per person. Not even 35. The usual overhead and red tape and waste that always creeps in will easily expand this to 35-40, and the crises that happen because the design is flawed or the user changes their mind or whatever will expand this to 40-45, 50 at worst case, which is tolerable for short spurts. The projects should be planned on the basis of 30 hours/week and people should wind up working 35-40 hours/week on the average. This way you'll get everyone's best hours and therefore their best work, and it also helps morale. And since I read somewhere that projects should be broken up into small enough tasks that could be done in about a week, that means about 20-30 hours for each task.
Routine 50-70 hour weeks are a sign of bad management. Sure, I routinely work 60-70 hour weeks but that's mostly due to the incredible resource constraints of growing a business on a shoestring in the face of too many of the usual obstacles to list here. But I'll also admit that my own management skills could use more improvement. And there's no way I could work these hours at all every week if it was mostly outside my home office.
Those who insist that it's not economically feasible to plan for less than 40 hours/week may appear to have a point in the case of travel expenses for contractors brought in from out of town, since the travel expenses are by day and by flight rather than by hour, but again, I'd suggest that being so insistent on on-site work and other criteria that one would bring in out of town talent may itself be questionable management, at least in some cases. If brokers and clients would stop hiding the travel expenses in a higher rate and show them separately, the economics could become more evident, but regardless, it's questionable except for very short, specialized projects.
Part of the reason that the best programmers are so much better than the worst is that they have good integration of both halves of the mind, as they say. It takes both intelligence and intuition to be good at highly technical and highly creative work like this. This is a major reason that micromanaged PHB-ridden environments are counterproductive. Intelligence, intuition, and especially the combination of both are easily tired and burned out if not refreshed by a well-balanced lifestyle. This is partly why it seems that many of the best programmers are also into music, art, fantasy role-playing games, underrepresented religious and/or political views, and offbeat hobbies. All work and no play makes not only the people but also the work itself suffer as a result.
Robert M. Pritchett, President - RMP Consulting Partners LLC - member ICCA
Quality means doing it right the first time
-- Robert M. Pritchett, December 19, 2000
Regarding employee's work hours:
I agree with the author, someone who works for 65/hours will be close to twice as productive as someone who works 40 hours, assuming that he is working for 65 hours per week by choice. If the workplace is more attractive than the home, it is locical that the employee would do this. The ideal programer will enjoy programing, and the ideal programers for a large project will enjoy working for 65+ hours / week while they are doing the project. My view for a sucessful company is one that highers all good programers available to them, and assigns smaller projects to those who wish to work less, while assigning large projects to small groups of 2-4 commited programers who want to work for 65+ hours / week, and then gives them optional large breaks afterwords.
-- klyde beattie, December 20, 2000
The author seems to believe that the only way to deliver a project on time is to work 60/70 hour weeks. Amazingly enough, it never occurs to him that perhaps people wouldn't have to work 60 hours a week if deadlines were realistic with the requirements and best practices, and projects were well-managed.
All the projects I've ever seen have gone over, even with programmers working overtime, because of poor management and ridiculous deliverable expectations.
-- Peter Risser, January 18, 2001
To respond to the comment above... I never said that the only way to deliver a project on time was to work more than 40 hours per week. If your project is installing Microsoft Exchange, maybe you can get it done in two hours. I was writing about young people building careers. If you just want to do what someone else tells you to do, I guess in 40 hours/week you can be pretty productive. If you want to make a contribution to the world significant enough that someone will remember your name, you probably need to spend some time (a) looking at what others are doing and figuring out something worthwhile and innovative to do, and (b) writing up what you did and demonstrating it to other people. These activities are going to take some extra time. That's why you don't recognize the names of too many engineers who've worked 9-5 M-F their whole lives. Maybe they designed a bolt on a landing gear on a Lockheed plane in the late 1960s. They were productive, in the sense that if they hadn't come to work someone else would have had to work a bit harder. But then the recession came and half the aerospace engineers were never able to find engineering work again. The guy who never built a personal reputation was then working as a greeter at Six Flags for $2.75 per hour.
Imagine if Microsoft, Oracle, Sun, and RedHat made products that simply worked and worked simply. All of a sudden half the people in IT would be out of a job. My article is about building an organization where all of the tech people would still be employable after such a shakeout.
-- Philip Greenspun, February 16, 2001
Greenspun's (previous?) response about people not remembering your name if you work 9-5 is not just defensive, but so patently stupid as to be offensive as well. I'd imagine there are tens of thousands of 60+ hour engineers out there--habitually, year after year--and I'd imagine none of you out there can name more than a few of them. They're in pretty much the same boat as the 35 hour engineers, except now that they've been laid off they have no families or friends to fall back on.
Philip's brand of reasoning was trashed pretty thoroughly in Crime_and_Punishment, but knowing how that worthless engie school in Mass treats the humanities, I'd guess we can't expect insight.
A brilliant idea may inspire you to work long hours (if you're too disorganized or otherwise committed to get them built in short hours), but working long hours proves nothing about your ideas (only about your priorities).
Philip's is a clear statement of the yuppie ethic: it doesn't matter whether you produce something of value, the important thing is to _take_credit_ for producing something of value. It's no wonder his fallback position is Professor.
Given his evident disdain for competent craftsmanship, it's no surprise his grandiose schemes end in disarray; and given his ethic it's no surprise this turns out to be someone else's fault.
-- David Zink, May 29, 2001
Related Links
Discussion of this article on slashdot- Discussion of this article on slashdot (contributed by Joel Londenberg)
How Software Companies Die- Orson Scott Card on what happens when the above advice is ignored. (contributed by David Eison)
Portland Pattern Repository discussion on the value of working OverTime- "That said, it is clear that the overall productivity goes down with LongHourWeeks." (contributed by Charles Miller)
They Write the Right Stuff- The group that writes the controling software for the space shuttle launch does it extremely well, and in 40 hour weeks. (contributed by Ben Heavner)
How to Manage Geeks- Eric Schmidt (CEO of Novell) gives a nine-point tutorial on managing geeks. (contributed by Kaushik Sridharan)
Whaddaya mean, you can't find programmers?- Another take on making a nice place to work for programmers. No mention of how many hours they work though. (contributed by Dave Bauer)
A Harsh Reality- Common industry practices which are intended to standardize and improve software quality often make things worse. (contributed by Robert M. Pritchett)
by Philip Greenspun (philg@mit.edu)
Sumbitted on: 2000-10-22
CCM Home : ASJ : One Article
--------------------------------------------------------------------------------
Philip Greenspun founded ArsDigita Corporation and was its CEO from inception until it reached $20 million/year in revenue. Currently, he is Chairman of ArsDigita and teaches computer science at the Massachusetts Institute of Technology. Why an article on managing people? And one written by someone with training in computer science rather than business administration? There are thousands of books on the best ways to manage people. Many of these books are excellent, having been written by people who've devoted their lives to the discipline.
Software engineering is different.
Software engineering is different because only the best people significantly contribute to achievement. Traditional management texts assume a distribution of talent among the workers. Each worker is contributing something useful and the challenge is to get each one to perform at his or her maximum potential. In the same factory, the best worker may produce two or three times as much as the average, but all the workers are contributing. In software engineering a good programmer is at least 10 times more productive than an average programmer (Brooks 1995). If a product is being developed rapidly, the average programmers will consume nearly their entire work day just in reading and understanding the new code generated by the good programmers. Thus the challenges of a software engineering manager first and foremost are (1) creating a work environment where good programmers will be satisfied enough to stay, and (2) creating a system via which average programmers can become good. In an ideal software engineering organization, there are still some average-quality people but these should be viewed as being apprenticed to the best people and being taught as fast as possible.
Software engineering is different because people at all levels of the organization perceive themselves to be equally intelligent. Consensus-style management can perhaps work when there is a gradient of perceived ability. Given enough time, the less able workers will follow the lead of the more able workers. One of the paradoxes of software engineering is that people with bad ideas and low productivity often think of themselves as supremely capable. They are the last people whom one can expect to fall in line with a good strategy developed by someone else. As for the good programmers who are in fact supremely capable, there is no reason to expect consensus to form among them. Each programmer thinks his or her idea about what to build and how to build it is the best. (See Kruger and Dunning's "Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments" for more on this topic.)
Software engineering is different because a leaf-node worker is more expert than any manager, even when the manager is a great engineer, in at least the small portion of the system that the leaf-node worker has personally built. This makes it difficult for a manager to engage in a technical argument with a worker. It becomes nearly impossible when the manager's technical skills are weak. The worker can spin castles of complexity in the air and come up with impressive-to-the-MBA excuses for why it has to be done a certain way or on a certain schedule.
Software engineering is different because the organization can't afford to lose the individual productivity of the best people by pushing them into management. A truly great programmer may generate 10 times as much business value as a merely good programmer. Can the organization afford to take someone who can do the work of 100 average programmers and push him or her into a pure management role? Probably not. Can the organization afford to put people with weak technical skills into management roles? Probably not. Once you give Joe MBA a title and ask him to coordinate eventually he will be making decisions that have engineering implications. Thus many of the best programmers are eventually forced at least to assume project leadership and mentoring responsibilites. Since they are still expected to produce designs, software, documentation, and journal articles, the danger is that the new manager will become glued to his or her screen and never look up to see how the project team is doing.
Software engineering is different because measurement is notoriously difficult. The world is full of products that failed due to overly complex and tasteless designs. Yet all of these designs were considered tasteful by their architects. Systems that experts evaluated and found wanting, such as the Unix operating system (1970), eventually proved to have great utility. It is a bit easier to count up the lines of code per day produced by a programmer but if the project was not very tightly specified originally, how do you know whether or not these lines of code are useful?
At this point a skeptical reader might be thinking that, while software engineering is different from line production work or any other endeavor with a manufacturing division of labor, there are similarities with research and development, management consulting, and financial analysis. This is certainly true but there aren't too many interesting books on how to reliably produce results in these fields (one is referenced in the "More" section below).
Ideas to Steal
Software engineering is different but it is not that different. What ideas can we steal from the broader world?
people don't do what they are told
all performers get the right consequences every day
small, immediate, certain consequences are better than large future uncertain ones
positive reinforcement is more effective than negative reinforcement
ownership leads to high productivity
people don't do what they are told
In Bringing out the Best in People, Aubrey Daniels notes "If we always did what we were told, we would eat only nutritious foods, never drink too much alcohol, and exercise regularly." There is thus a natural limit on the effectiveness of written policies and management by telling then nagging.
A corollary to this principle is that people do what you reward them to do, not what you hope they will do. Often, when you look at what is truly rewarded in an organization, you find it is different than what you think is rewarded. Do the managers have an engineering background? If not, they'll probably be unable to perceive when a programmer is accomplishing nothing. So the programmer who does nothing gets a paycheck at the end of the month. Having thus been rewarded for doing nothing, the programmer tries it again the next month...
all performers get the right consequences every day
The natural way to manage is to spend time with people who aren't doing a good job. You help them out. You remind them of the good things that can happen to them if they finish a project or raise the spectre of their being laid off the next time the company needs to improve its profitability. These are probably the right consequences for someone who is underperforming. But what about the people who are performing? What if you ignore them day-to-day? Unless they are getting positive reinforcement from another source, they may stop coming in on the weekends to get a release out the door earlier, stop documenting their code, stop writing journal articles. A top performer won't sink to the level of a problem employee but that person may become average. And in the long run a company with average workers will at best earn an average return on equity.
small, immediate, certain consequences are better than large, future, uncertain ones
An annual review and bonus is not classically considered a very good way to motivate people. It is too far away, especially in a dotcom economy. Even if a worker is able to keep the bonus goal fixed in his or her head for the 365 days preceding the bonus allocation, there is uncertainty attached to it. What if the company is doing really badly at the end of the year? Will there still be a bonus?
positive reinforcement is more effective than negative reinforcement
Like most schools worldwide, MIT practices negative reinforcement at the undergraduate level. If student does not do a problem set by a certain deadline, we give him or her a bad grade. This has turned out to be extremely effective at ensuring that an MIT graduate has achieved some minimum standard. However, the students don't accomplish all that they could. The first term that we taught 6.916, we gave the students one week to do Problem Set 1. It was pretty tough and some of them worked all night the last two nights. Having watched them still at their terminals when we left the lab at 4:00 am, we wanted to be kinder and gentler the next semester. So we gave them two weeks to do the same homework assignment. The first week went by. The students were working on other classes, playing sports on the lawn, going out with friends. They didn't start working on the problem set until a few days before it was due and ended up in the lab all night just as before.
We thus proved the management adage that a deadline just gives someone an excuse to procrastinate and do nothing until the very end.
Graduate school at MIT is different. We want the students to do research, write up their results, publish them in journals, and graduate with a reasonably interesting PhD thesis. If a student finishes some research, the most effective faculty advisors immediately provide positive reinforcement by paying attention, helping design the next experiment, helping to draft a paper outline. If the student finishes a write-up, he or she is positively reinforced by being sent to a conference to present it. If the student finishes a PhD thesis, he or she is positively reinforced by being given a 3-7X pay raise.
The lesson from MIT? Negative reinforcement can work if the organization is extremely tightly managed, if the consequences are small and immediate (usually a problem set is due every week and only represents a part of the final grade), and if the goal is to make sure that everyone comes up to a reasonable level. However, the worldwide fame of MIT rests on research achievements by graduate students. This innovation is mostly supported by positive reinforcement.
ownership leads to high productivity
A related issue to positive/negative reinforcement is ownership. Non-ownership systems discipline those who are not working up to the minimum standard, but they do not offer enough of an upside to truly motivate people. Moreover, non-ownership systems demand a very accurate setting of standards. Ownership-oriented systems include contingent rewards with an almost unlimited upside, and are thus effective at getting as much discretionary effort out of workers as possible.
As an example, in the early days of ArsDigita we had only a handful of customers: America Online, Environmental Defense Fund, Hewlett-Packard, Levi Strauss, Oracle Corporation, and Siemens. We had only a handful of programmers as well and hence the easiest way to divide the work was to give a programmer total responsibility for one project. The programmer owned that customer. If the project went well and the customer wrote us a big check, we gave nearly all of the money directly to the programmer. If any project had gone poorly and we'd been fired by a customer, we would not have had to think very hard to figure out who was responsible (fortunately this never happened while I was running the company!). People worked insanely hard to make their projects successful and their clients happy. More importantly, the programmer who did an entire project by him or herself learned enough to train new people, lead a larger project, etc.
After we grew beyond the 40-person mark, pressures to dilute the ownership aspects of our organization grew. We wanted to grow rapidly--nobody wants to buy enterprise software from a small company, even if the software happens to be open source. As our reputation grew, customers came to us with larger projects. We believed that many of our developers were too junior to handle complete responsibility for these large projects. Our costs went up because we had to coordinate the diffused responsibility. In the summer of 2000, when we had 200 or so employees, one of our clients was unhappy. It took a week just to arrange a meeting among the five managers who bore collective responsibility for the project! Meanwhile, individual productivity fell. It was taking more programmer-months and more calendar months to get things done. On weekend mornings you could walk naked through an entire floor of our headquarters building without fear of embarrassment.
(At the time of this writing, there is a proposal on the table to consolidate some of the separate management pyramids, thus taking us back closer to our original structure.)
Building and keeping a good software engineering team
What is the best way to attract some good software engineers to your organization? Hire a few to begin with. Good people like to work with other good people. This is true in every field but much more acute in software engineering. Why? Consider two management consultants working on different projects but within the same organization. If Consultant A does a bad job it harms Consultant B's reputation to some extent but does not require Consultant B to take any action. Whereas in most tech companies if Programmer A does a bad job it usually means that Programmer B will eventually be forced to use the bad code, read the bad code, and then fix the bad code.
What attracts good programmers? Traditionally the best programmers seek the most challenging problems. They want to work in an organization that is trying to build something important. Programmers have huge and fragile egos. If they are somehow assigned to a trivial problem and that is their only possible task, they may spend six months coming up with a bewildering architecture more complex than the Windows 2000 operating system, merely so that they can show their friends and colleagues what a tough nut they are trying to crack. Another source of ego-gratification for programmers is to have other programmers admiring their work. Open-source software projects thus have a big recruiting advantage over closed-source software companies.
What kind of working environment is necessary for programmer satisfaction? Good programmers want to achieve and therefore removing barriers to achievement is the most important step that one can take in creating an effective working environment. Programmers dread elaborate process, endless meetings, and layers of marketing approval before a product can be shipped. Ideally it would be possible to conceive a product on Friday evening, set up the development environment Friday night, write code on Saturday and Sunday, test on Sunday night, and ship on Monday morning. Maintaining this kind of freedom is a serious challenge as a company grows and its products become more complex. Successful companies such as Oracle Corporation burden their marketing departments with overlapping products rather than stifle programmer initiative. For example, during most of the late 1990s there were at least three different Web servers that you could buy from Oracle, each one backed up by a document explaining why it was the one true path toward database-backed Web site glory.
A good physical working environment is essential. Great programmers get a lot of positive reinforcement from their work itself. They write some code and immediately can see it dance. That keeps them at work for hours that, while they would not impress a taxi driver in Singapore or a factory worker in Guangzhou, will surprise many American business people. When we hired an architect to lay out the interior of ArsDigita's first building in Cambridge he surveyed the programmers and came back shaking his head: "I've never seen any group of people who spend so many hours continuously sitting at their desks."
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.
Your business success will depend on the extent to which programmers essentially live at your office. For this to be a common choice, your office had better be nicer than the average programmer's home. There are two ways to achieve this result. One is to hire programmers who live in extremely shabby apartments. The other is to create a nice office. Microsoft understands this. In the early 1990s they did radio spots with John Cleese as a spokesman. One of the main points of the ad was to ridicule the cheap open-plan offices in which programmers were traditionally housed and promote the fact that at Microsoft each developer gets a plush personal office.
How can an office be nicer than one's home? Let's consider the following dimensions:
social
physical comfort
aesthetic
entertainment
attractive
Social
It is easy for an office to beat the home on the social dimension, especially if the programmer lives alone. If there are people at work at all times of day and night and you've succeeded in building an organization of good people, ipso facto there is always someone interesting to talk to at the office. To exploit fully the social possibilities of the programmers' office, it is important to have informal gathering spaces. At the MIT Artificial Intelligence Laboratory, which has nurtured groups of great programmers for nearly 40 years, the gathering spaces are referred to as "playrooms". These contain sofas and coffee tables, movable in the best tradition of Dewey, where programmers eat, talk, and occasionally listen to presentations. Usually a playroom will have some sort of shared writing surface such as a whiteboard. Note that these playrooms also are an important part of an organization's knowledge management system. You need to give programmers from different projects a place to meet where problems can be discussed and solutions from older/other projects can be suggested.
A social place will never be friendly if it is trapped behind a high wall of security. It ought to be very easy for a programmer to invite a friend over. If programmers are comfortable meeting their friends at the office it greatly increases the likelihood of friends recruiting friends.
An open office plan contributes to making the work environment stronger on the social dimension.
Physical Comfort
A programmer's work environment should be a supremely comfortable place to sit, look at information on a screen, and type. At ArsDigita we accomplish this via providing Aeron chairs, the keyboard of the programmer's choice, and at least two monitors. In the summer, the place should air-conditioned 24 hours per day, 7 days per week. In the winter, the office should be heated and humidified (often neglected). The air should be cleaned year-round with high-efficiency mechanical filters and electronic cleaners so that allergy sufferers are not discouraged from working.
One horrible mistake that we made was letting our architect design the workstations. Each programmer was given a 6'x2' desk, 12 square feet total. Two 21" monitors took up so much depth that there wasn't even room for a keyboard. Immediately we had to toss our monitors and get flat panels (cost about $400,000 extra). IBM had a better architect for its Santa Theresa facility: Gerald McCue. He found that each worker needed 100 square feet of dedicated space and 30 square feet of work surface. McCue also found that programmers needed noise isolation from enclosed offices or high partitions but personally we think this rule is worth breaking in a dotcom world where a team has to work fast and in sync. Better to manage noise by spreading desks apart a bit so that there are fewer programmers in a given area and therefore fewer conversations, fewer telephones, and more opportunities for sound to be absorbed before reaching someone's ear.
Aesthetic
Programmers don't have the same need for wood-paneled expensive plushness that, say, corporate lawyers or investment bankers might. However, the office has to be aesthetically satisfying or it will be tough for anyone to take seriously the idea that the company values aesthetic internal design of computer programs. Similarly, the office has to be finished and well-executed or nobody will believe that the organization is committed to finishing products. In the long run it is impossible for an organization to be excellent in one area and mediocre in all others. So the physical facilities have to look as though they were planned and decorated by someone with taste. Note that this need not be expensive. You could do it with $200 desks from Ikea and a consistent set of art posters on the walls. But an expensive facility with blank walls and boxes left over from the last move screams incompetence. Remember that the overall place has to look nicer than most of the programmers' houses.
Entertainment
It is easy to make an office more entertaining than the average person's home. Most people have a TV at home but they don't have friends with whom to watch it. Nor will they typically have the kind of big-screen equipment that is easy for a company to acquire. In the 1980s students at the MIT Media Lab would gather on quite a few nights to watch movies from analog laserdisks, presented with a very high quality projector. After the movie was over, they'd go back to their desks and work for a few hours, something that would not have happened if they'd gone out to the movies.
The average home cannot accomodate a pinball machine. An office can. The average home can have video games, which are very popular with young programmers, but not people with whom to play. The average home cannot have a grand piano but almost any office can.
Attractive
A worthwhile goal is to have at least one thing that is extremely attractive about the physical enivronment for any particular prospective software engineer. Here's a possible list:
dog-friendly policy
grand piano
climbing wall
indoor garden
aquarium
koi pond
exercise room with fancy machines
pinball machine
Not everyone has a dog. Not everyone can play the piano. Not everyone wants to practice rock climbing. But by having a long list in the same building, there is a good chance that at least one item will be very attractive to a particular person. If a person loves gardens, he or she can be seated at a desk within view of the garden. That person won't value the other items, perhaps, but another employee will.
Change of Venue
You can work on all of the preceding dimensions but there will come a day when a programmer gets restless. Sitting at exactly the same desk every day is tedious. We thought that we could solve this at ArsDigita by using the Internet and our branch offices. We'd encourage programmers from Cambridge to pick up and work at a spare desk in the Berkeley or Pasadena offices for a week or two. The idea did not catch on, however, because it turns out to be disruptive for one person on a team to disappear. One of the reasons we've found open-plan offices effective is that it helps to have one's team members close enough to look casually at what is on the screen.
What does it take to let the entire team pick up and work somewhere else for awhile? A beach house or a ski house within a two-hour drive of their main office. It is kind of expensive for an individual to rent a vacation house year-around, equip it with a DSL line or cable modem, and pack it with enough desks and computers for a team to work. But if you've got a group of 30 programmers and get a house large enough for 6 or so to sleep and work, the cost is manageable. In the winter, a programming team can disappear for a week, ski every morning and work all afternoon and evening. In the summer, a team can spend a week looking out at the ocean... while typing most of the time. It costs more than not having the beach house but a lot less than having employees go off on their own to have fun every weekend and not work.
Turning average programmers into good programmers
It is difficult to hire the most productive programmers in the world. Oftentimes these people are capable, by themselves, of turning out entire products, and thus they start their own companies. If a really productive programmer works for an established organization, that organization will usually take extreme steps to keep him or her. Thus beyond a certain point it is most effective for an organization to develop a strategy for creating good programmers internally.
How does one create a good programmer? Raw materials are important. You want someone with a strong computer science education, a high IQ, and an ability to communicate effectively in oral presentations and in writing. But without the right experience, such a person will never be more than an average quality programmer.
These principles are important in building up someone's programming skills:
A person won't become proficient at something until he or she has done it many times. In other words., if you want someone to be really good at building a software system, he or she will have to have built 10 or more systems of that type.
A person won't retain proficiency at a task unless he or she has at one time learned to perform that task very rapidly. Learning research demonstrates that the skills of people who become accurate but not fast deteriorate much sooner than the skills of people who become both accurate and fast.
Technology shifts force a programmer to go through bursts of learning every year or two.
Look around your organization. You can make a list of the people qualified to design and build a new system by counting up those who've built 10 or more similar systems in the past, at least two in the last year, and that could do the entire job in a month or two if they really had to. These are your "good programmers". Everyone else is a candidate to be turned into a good programmer as quickly as possible.
Learning to design and build software systems requires that the programmer design and build software systems. These can be smaller subprojects for internal or external customers, standalone software system for non-profit organizations, or demonstration systems to be written up and distributed to other programmers. A particularly effective option that is only available in the Web world is to build and launch a free public service. See http://remindme.arsdigita.com and http://towzone.arsdigita.com for examples of one-evening training projects.
Whatever the training task, the pace must be ruthlessly brisk. The learner should be expected to build at the same pace as an experienced developer. The difference between the learner and the wizard is that you expect the learner to make a lot of mistakes. The system as built may be awkward or not handle error cases properly. That's okay. Training research shows that if you get speed now you can get quality later. But if you don't get speed you will never get quality in the long run. We practice this technique in 6.916, Software Engineering for Web Applications, our course at MIT. Each student builds five database-backed Web applications during the 13-week semester. The first few that they build, during the course of the problem sets, are not necessarily elegant or optimal, but by the end of the semester they've become remarkably proficient, especially when you consider that each student is taking three or four other classes.
If you see one of your best people walking out the door at 6:00 pm, try to think why you haven't challenged that person with an interesting project. If you see one of your average programmers walking out the door at 6:00 pm, recognize that this person is not developing into a good programmer. An average programmer's productivity will never be significant in a group of good programmers. If you care about profits, you must either come up with a new training program for the person or figure out the best way to terminate his or her employment with your organization.
Still not convinced? Take a look at the Japanese "code factory" circa 1990. These precisely organized large organizations where each person had his role, however small, were supposed to overtake the American approach where small teams of craftsmen worked in a comparatively disorganized manner. The factory approach sometimes produces acceptable corporate IT solutions but for innovation and successful product development, the craft approach has been overwhelmingly vindicated.
Turning good programmers into good managers
As noted in the introduction, software engineering is different because the organization can't afford to lose the individual productivity of the best people as they are pushed into management. At ArsDigita, for example, a manager who is one or two levels up from the leaf nodes is still expected to write code, develop SQL data models, write system design documents, and write journal articles. Yet managers who are spending a portion of their time designing software or writing documentation are at risk of neglecting their duties to review subordinates' work.
The classic problem situation at ArsDigita is a manager getting lost in his or her own work and failing to review a subordinate's efforts for two or three months. When the review occurs, inevitably the subordinate has either been working on the wrong thing in the wrong way or hasn't been sufficiently productive. At this point the manager is really angry. Three months of calendar time and money have been wasted. But should the manager be angry with the employee? If the manager had reviewed the subordinate every week, the company would never have been at risk of losing more than one week of time and money.
Our solution is to decouple responsibility for review from responsibility for scheduling review. We use administrative assistants to ensure that each manager is scheduled to look at every subordinate's work at least once per week, more frequently in the case of junior employees. It has proven remarkably more effective when a neutral third-party is responsible for scheduling than when people with incentives to shirk are responsible for scheduling.
Management by Consensus Considered Harmful
Leaf-node engineers at every company on this planet think that they have better business ideas than the senior managers. Why not simply turn the company over to the engineers to run? Each engineer has a different set of better business ideas.
Software engineering companies will tend to have a fairly flat distribution of intelligence. The 22-year-old Stanford CS punk that was just hired will be just as smart as the 30-year-old lead engineer who will be just as smart as the 40-year-old CEO. Within a company's technical team, the raw IQ differences are even smaller. If each member of the team were playing the Bach Partitas and Sonatas for Solo Violin, the wrong notes, shaky intonation, and bad phrasing would make it pretty obvious to the novices that they needed to take advice from the experts. But because software quality is tough to measure and software quantity is seldom measured, the novices in a software engineering group are able to think of themselves as experts.
What would be wrong with a completely egalitarian software engineering group? Maybe the entire team really is at the same level of ability. And suppose that somehow the challenge of getting everyone to attack the same problem had been surmounted. Remember what Fred Brooks said in The Mythical Man-Month: high quality systems must be architected by no more than two people.
Getting design input from leaf-node engineers is important for having a good product design. But at the end of the day nobody should be confused as to who is providing leadership. There is an irreducible amount of Engineer A imposing his or her design on Engineer B. This can lead to some harsh-sounding words and bruised feelings. Microsoft is not the self-esteem company, at least if you believe Playboy magazine's interview with Bill Gates: "We hear you're brusque at times, that you won't hesitate to tell someone their idea is the stupidest thing you've ever heard. It's been called management by embarrassment challenging employees and even leaving some in tears." Truly elite organizations can be far worse than Microsoft. Ask a group of surgical interns and residents how much respect they get from the surgeons. Go into a world-class biology department and ask the grad students and post-docs about their treatment at the hands of the professors.
Wherever You Go, There You Are
Performance management textbooks will tell you that workers don't improve unless they get feedback. Joe Widgetmaker should get a nice chart, updated daily, of how many widgets he has produced personally each day, and how many have been built by his team.
Consider the average working programmer's life:
surfing USENET
surfing Slashdot
reading docs
questioning colleagues
writing specs and designs
writing docs
writing code
testing code
fixing bugs
filing bug reports on others' code
attending meetings
helping sales and marketing staff
(For comparison to the grad student life, see http://philip.greenspun.com/humor/graduate-student-emotion-check-list.)
Characterizing this person's productivity is going to require more than one number. But if we don't do it, days or weeks could slip by without the programmer realizing that his or her achievement levels are plummeting. In a company with disorganized or technically clueless managers, the programmer's supervisory chain won't notice the lack of achievement either.
Production of documentation and code is generally measurable by reference to the company's version control system. Bugs filed and fixed are easily tallied by looking at the company's ticket/bug tracking system (see http://www.arsdigita.com/doc/ticket for a description of our favorite open-source ticket/bug tracker). The softer stuff can still be quantified but it will have to be done by humans filling out forms.
Ideally the programmer will get daily feedback, which is kept private unless the individual elects to publicize it. Performance in each sanctioned area of activity will be marked up and scored with a weight. The programmer can then see if his or her crude achievement level is going up or down.
Summary
Building and managing a peak-performing software engineering organization is challenging but extremely profitable. The core Ariba product was written by two programmers, yielding a market capitalization of $30 billion. Microsoft Internet Explorer is a much better browser than Netscape Navigator and yet it was written by a much smaller team: only about 30 developers.
Start by attracting a good core team, perhaps by setting up an organization that enables each engineer to excel along the axes defined in http://www.arsdigita.com/asj/professionalism. Provide a productive working environment and a physical environment that is better than the average programmer's house. Provide daily positive reinforcement. Provide daily feedback showing the programmer more or less exactly what he or she has accomplished, plus a graph for the preceding few months showing the trend. Aim to install a feeling of ownership in each worker.
More
Bringing out the Best in People (Aubrey Daniels 1999; McGraw Hill). 200 pages containing 75 pages of good ideas plus the usual business book filler. But the ideas are genuinely good.
The Mythical Man-Month (Fred Brooks 1995)
Managing the Professional Service Firm (David Maister 1993). In terms of having an equal distribution of ability among all levels of the enterprise, the closest industry to software engineering is management consulting. Maister's work is a classic guide to success in this industry.
"Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments", Justin Kruger and David Dunning 1999, Journal of Personality and Social Psychology
Peopleware (Tom DeMarco and Timothy Lister 1999); page 98 is worth the price of admission, explaining that "the term unprofessional is often used to characterize surprising and threatening behavior. ... In a healthier organization culture, people are thought to be professional to the extent they are knowledgeable and competent." (See http://www.arsdigita.com/asj/professionalism for ArsDigita's independent conception of this idea.) Much of the rest of the book is a celebration of the 40-hour work week and the claim that "overtime" in the long run is never beneficial. If the authors were correct, Silicon Valley would be the poorest region of the nation, with Redmond, Washington the 2nd most impoverished. And Washington, DC would be our great source of innovation and productivity. Peopleware was probably written to help ensure success for internal corporate IT projects where there isn't any competition and delivering three months late won't change much.
Making the Cisco Connection : The Story Behind the Real Internet Superpower (Bunnel et al 2000) -- shows how ignoring the "no overtime" admonitions in Peopleware can generate $400 billion in market cap.
Parkinson's Law (C. Northcote Parkinson 1958) -- how management really works in the long run
A Pattern Language (Christopher Alexander et al 1977) has very interesting things to say about physical space and social organization.
--------------------------------------------------------------------------------
Submitted by Philip Greenspun (philg@mit.edu)
Reader's Comments
A corollary to this principle is that people do what you reward them to do, not what you hope they will do. Often, when you look at what is truly rewarded in an organization, you find it is different than what you think is rewarded.
This is illustrated by the classic business school article:
Kerr, S., 1975, "On the Folly of Rewarding A, While Hoping For B," Academy of Management Journal, Vol. 18, pp. 769-783.
It represents exactly what you are saying.
-- Tyler Pruett, October 30, 2000
Philip, your ideas on rewarding programmers are excellent. However, I don't believe number of hours worked defines a good developer. Programmers get older and have families. Saying that they have to log a certain number of hours in the office is stupid, almost like IBM counting programmer productivity in "K-Locks" (thousands of lines of code).
A good developer can often finish what an average one can do in half the time an average developer can - with less bugs and with better documentation.
A couple of good books on this topic include,
"Software Project Survival Guide by Steve McConnell"
(Somewhat dry - but good reference book)
First, Break All the Rules : What the World's Greatest Managers Do Differently
(Not one of the typical management books - this one has some actual research behind it.)
Microsoft Secrets : How the World's Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People
(A few good chapters worth reading)
-- Anthony Barker, November 6, 2000
... the average programmers will consume nearly their entire work day just in reading and understanding the new code generated by the good programmers
I would argue that the phrase above should be reversed: ".. the good programmers will consume nearly their entire work day just in reading and understanding code generated by the average programmers". If the programmer is good, the code will be elegant, easy to read, and practically self-documenting (not that that's necessary because the good programmer would have also written lots of clear concise comments as well). Average programmers will make a mess of the design and would take anyone more time to figure out what the heck they were thinking.
-- Dion Loy, November 6, 2000
Bricks and mortar still seem to play an important role in programming, even in a profession where much work can be done offsite.
My preferred work environment happens to be my home. However, even with a good background (linux, java, C, C++), a good work history and a monetary incentive (the lowly Canadian dollar), most companies aren't willing to entertain the thought of a telecommute position.
While communication among programmers is important and our modern communication tools are far from perfect, it amazes me that companies are still so focused on employees "being there" rather being focused on what they produce. They would rather pay for relocation and expensive high tech cubicle real estate and measure performance by attendance.
-- darrell pfeifer, November 6, 2000
I agree with the poster above about reversing the comment about time spent understanding others' code. An excellent resource about this concept is Code Complete, by Steve McConnel. Given that (I forget the exact number, but it is well over 50%) of programming time is spent maintaining or modifying existing systems, what makes a good programmer is a programmer who can write code that is very easy to understand for the next programmer to come along and have to deal with it. Easy to understand code is quick to get up to speed on and is also conductive to fewer defects, because a lot of defects can be caused by a later programmer misunderstanding exacly how the existing code works. Just getting the code to work in an efficient manner is not enough. If it is excellent code, but cryptic, then it will waste a lot of time (and money) later when someone other than the original developer has to deal with that code. If the design is good (perhaps not super-excellent, but gets the job done) but extremely easy to understand, then time (and money) will be saved later on. A single good programmer can probably rambo-code out a system faster than a group of programmers, but that rambo code that saved so much time for the first release will come back and haunt all future releases - completely erasing any initial cost savings advantage in the long run.
-- D Goodkin, November 6, 2000
Another excellent book on managing programmers is Weinberg's "The Psychology of Computer Programming". (Ignore the technology of programming in the book, look at the message underneath.)
One fundamental objection that I have to the thesis of this article is that one must sacrifice all non-work life to the coding at hand. While at a previous employer, they had internal studies and some external studies of hardware and software engineers that showed steady declines in productivity after more than 1 month of serious overtime worked. This was at a site that turned out very large custom systems at the bleeding edge of digital hardware and software capability, with very high productivity (3-5x industry average overall), even with large project teams (400+ engineers). Their key to getting things done was by having a strong systems engineering group that allowed the problems to be broken into manageable chunks so that the staff could concentrate on their chunk and not spend huge amounts of time in meetings. They also sent everyone to training on the systems and software engineering process so you knew your way around. We worked an average of 45-50 hours/week and generated quality code at very high rates.
-- Edmund Hack, November 6, 2000
I would like to suggest a correction to the article:
Mr. Greenspun uses the notion of reinforcement in regard to managing people. Alas, he made a serious error when he used "negative reinforcement". I believe that where he uses "negative reinforcement", he should use "punishment" instead.
While I have a degree in Computer Science, I did take an introductory course in Psychology, and the definitions of positive and negative reinforcement and punishment were well explained. In this context:
Positive reinforcement:
A programmer writes a lot of really good code (behaviour), so you give him a lollipop (the positive stimulus), which you expect will increase the likelihood of that behaviour recurring.
Punishment:
A programmer writes some bad code (behaviour), so you take away his foosball machine (punishment), which you expect will decrease the likelihood of that behaviour recurring.
Negative reinforcement:
You hire someone to lash a programmer continuously (the negative stimulus) until the programmer learns to escape it (removal of the negative stimulus) by writing lots of good code (behaviour). This will increase the likelihood of that behaviour recurring. It is hoped that the subject will eventually learn to avoid the negative stimulus entirely, rather than merely escaping it. :-)
Clearly, both positive and negative reinforcement result in an increase in the frequency of a particular behaviour, but punishment decreases it.
For other information on this, simply visit http://www.google.com/ and search for "reinforcement punishment positive negative" and check out the results.
Yes, I know that this may seem nit-picky, but just as we in the computer industry appreciate it when our jargon is used correctly by those not in it, I'm sure the psychologists of the world would appreciate it if we used their terms correctly.
-- Kevin McGregor, November 6, 2000
If you see one of your best people walking out the door at 6:00 pm, try to think why you haven't challenged that person with an interesting project.
I would be more inclined to believe that this person has a life, and is balancing it with their work.
People don't live to work, they work to live.
-- Paul Collins, November 6, 2000
Dog-friendly offices may be great for dog owners / lovers, but aren't as wonderful for people with allergies or even those who just want to be able to concentrate on writing code without having a dog try to jump on their lap.
-- Kevin Scaldeferri, November 6, 2000
I have to disagree with the comments about cubicles being acceptable in the dot com environment so that "people can see what's on others screens". The company I work for provided separate offices. Normally the doors are open so people can interact, and people interact just as much as they do in the open concept offices I have been in. The distractions however, do not occur and everyone is much more productive here than in the other places I've been.
-- Thomas Dean, November 6, 2000
Programmers who are measured based on how late they stay at work will quickly figure out how to excel at staying late without being more productive (e.g. come in at 11:00 am).
This article reinforces many great ideas from Frederick Brooks but, unfortunately, regurgitates a few tired stereotypes. Most programmers that turn 30, get married, have a few kids (that go to bed at 7:00), may as well resign themselves to being put out to pasture.
Here's an idea. Instead of just assuming that it takes 25 hours a week for team coordination and build your management approach upon motivating programmers to work more hours, why not work to reduce the time it takes to coordinate through better management and more efficiency? Isn't that what management really is?
-- Tom Wilson, November 6, 2000
The premise of this article seems to be that, if the workplace is sufficiently attractive, work will become the employee's top priority. While this is true in some cases (e.g. young people right out of school) it is not the case for nearly everyone else for whom family is likely the top priority. And even a very young employee may already be married.
While it is probably possible (and may be advantageous) to run a company filled solely with people for whom work is their top priority, it seems like a very difficult long-term strategy fraught with the danger of burn-out (despite the ski house "vacations" and such.)
Are success and a 9-5 schedule really incompatible?
-- John Siracusa, November 6, 2000
Microsoft Internet Explorer is a much better browser than Netscape Navigator and yet it was written by a much smaller team: only about 30 developers.
I'm surprised to hear this from Greenspun...
-- Anson Ann, November 6, 2000
The article is great, save one persistent misconception -- it is not necessary to work so many hours to be a great programmer. Yes, at times, the great programmers go larval and spend lot's of time hacking code. But the author's comment about seeing your programmers going home at 6pm and making the judgement that they should be challenged to stay longer is quite destructive.
I have worked the 70 hour weeks, it was fun, and we did great things. But there was also some great loss (to friends and family) induced by those long hours. I find it disturbing that the article basically encourages managers to find people whom can be coerced (incented, challenged, pick your euphemism) into working such long hours at the expense of all else.
There are some truly great programmers here where I work who wouldn't be here if management followed that advice.
-- Ron Forrester, November 6, 2000
While I generally agree with most of the material presented in this article, I have to take issue that there is some linkage between working long hours and productivity. As a software engineering manager, I generally found that I had to send people home to keep them productive. After 8 or 9 hours, regardless of skill level programmers lose their edge and cannot concentrate. In some severe cases, really good engineers can burn out. I had one developer working for me who wanted to work a twelve hour day ($$$). I vetoed the idea, my management overruled me, and three months later the engineer, whom I very highly regarded, had a nervous breakdown and was lost to the company.
Another thing that must be taught, and I did not see this in the article at all, is working hard vs. working smart. Unfortunately, there is a lot of grunt work when developing software products. Tools, whether purchased or built in-house can really help improve both productivity and morale. But software engineers, especially the neophites, may not realize this. I always stressed to my teams that if there were repetitive operations being performed, they should think "tool". A lazy programmer is a productive programmer.
-- Brian Berenbach, November 6, 2000
This is a great article on software engineering with plenty of good examples on the difficulties of managing software engineers. Every manager should read this to gain a proper perspective on managing a project. But, I disagree with this one statement:
"One of the paradoxes of software engineering is that people with bad ideas and low productivity often think of themselves as supremely capable."
How can anyone be so arrogant? Maybe these people are so lost, that this is the only conclusion they can accept? Nah...it's gibberish.
On the other side of the coin, how does software engineer find a circle of good programmers, since determining good/great programmers is already extremely difficult? Being a "leaf-node" myself, I am constantly trying to rate the software landscape and trying to determine the next Ariba or Internet Explorer. Some say it's impossible and I'll never find that opportunity. Is it inevitible to always have bad programmers/members on the project? Are we all doomed to one end or another to manage these "bad idea and low productivity" people?
-- David Peng, November 6, 2000
RECIPE FOR CARPAL TUNNEL
"the architect never saw so many ppl sit in a chair so long." i winced as i read this. why? because scrolling with the mouse makes my hands hurt.
I am a guy who would program 100 hrs/wk b/c i liked it. in fact, for a few years i did. for me aD would be a dream. but now it is only that. why? b/c after all this typing my hands are ruined. i cannot use a keyboard properly; only for very short times. fair warning to all aD ppl. once your hands or other health are gone, so is you job. and there are only so many opportunities in radio.
P.S. I have a degree from that other school in cambridge. it doesn't matter when you're disabled. you just get the boot and nobody wants you. you can't be a manager b/c u still have to use a PC. so forget about families, you won't get one.
note -- and you must post anonymously so you don't lose any temp job u might have (atm. pr writing with dragon nat speak, a nightmare to use) where they get the idea u are a dead weight
-- asf asdf, November 6, 2000
A few years back I worked on a project that required long hours. We started out at 60 hours per week; nine months later we were at 120 hours per week (of course, a significant portion was wasted). Morale was not too bad throughout the project, as the company was depending on it, and committed extra resources (dinner weekdays, lunch and dinner on weekends). The results were something less than great: the product was very buggy when it shipped, and it resulted in a significant market loss. More than 50% of the core team left within three months. There was at least one divorce.
This is an extreme example, but I have found in several different environments that extended hours are counterproductive, more often than not.
-- John Wilkinson, November 6, 2000
Where does Greenspun get the idea that coordination time, etc. is constant while coding time is not? The math he uses to calculate that 55 hours per week is 2x as productive as 40 hours per week is incredibly sloppy, especially considering how he uses it to justify firing workers who leave at 6.
I expect there's a lot of variance from the 25-hour figure he pulled out of thin air, mostly in the downward direction. 5 hours would be more typical where I work.
Sadly, there are probably some managers out there who will take Greenspun's advice. Probably the same ones who get alarmed when 40% of sick days are taken on Monday or Friday.
-- Bruce Lewis, November 6, 2000
I think two views can be seen on the issue of working long hours:
Measuring the number of hours worked as a means to measure productivity is totally wrong. The only thing that should count is when the product is shipped, and that the employees are fit for the next project.
The suggestion that people that leave by 6.00 are either understimulated or won't grow is very dangerous. I'ld rather have a good programmer leave by 6.00, knowing that his wife (yes, many programmers actually do have both friends, SO's and children) won't hate his work and that he will return the following morning, rested.
The second view is that the company really don't care about the long-term risks of having to replace employees as they get worn out by the hard work. From a HRM perspective, it is wrong, and from a long-term economical perspective, it is dangerous.
But, if the goal of the owners is to produce a couple of killer applications quick, and then cash in on the sale or IPO of the company, that's really the way to go!
/Fredrik Lundström, Software designer
-- Fredrik Lundström, November 6, 2000
Everything in Philip's article is dead-on, except for one MAJOR issue: working your top people like dogs is the fastest way to have them find the door.
Burnout is a fact of life, and it happens to the best of people. If those people are your best people, you're in big trouble.
A characteristic I have seen of the top-end programmers is an ability to self-regulate. They'll get what they're working on done when it should be done (remember, no-one can accurately schedule SW eng problems beforehand, to paraphrase Fred Brooks). If you take away the freedom to self regulate by forcing continual ridiculous hours, they're going to leave.
After all, if they're working 40 hours, they're still producing the equivalent of 400 "average programmer hours". Does anyone really want to lose that?
-- Stephen Drye, November 6, 2000
Overall, I thought the article was a good one, except for the part about "long hours == productivity". I think many of the issues people have raised about that point are right on, but I'll add one more:
Before I got older, got married, etc., I used to work much longer hours. In my experience, being at work for more hours did NOT increase my productivity. I noticed that most of the engineers who were working those long hours were spending a lot of time talking, surfing the web, playing pinball or air-hockey, etc. Your article hints at this when it discusses the need for making the work environment more comfortable and entertaining. If engineers were doing nothing but working for those 70 hours, why would they need entertainment while at work?
-- Andrew Shebanow, November 6, 2000
It is true that 70 hrs/wk can cause health problems if poorly planned. But 70 hrs/wk in a quality low-stress environment is far healthier than 40 hrs/wk in a bad-quality high-stress environment. That is why many people work 80hrs/wk in small companies and are happy wherease they would be miserable at 40 hrs/wk in large ones. It is the manager's role to eliminate the stresses to maximize health and productivity.
The key underlying factor is the amount of stress on the individual which will break down the individual at their seams, either mental or physical. Stress may be in unclear job demands, separation from family, disorderly work environment, lack of creativity, etc. Simple quantity of labor is not the highest workplace stressor (although it is a symptom that often exists in high stress environments). To reduce stress employees must be part of a well-planned process.
Speaking from experience, carpal tunnel and musculo-skeletal disorders can be avoided through proper programs of exercise, stretching, yoga, meditation, scheduled breaks, and nutrition to reduce psychic and physical stress and strengthen the body at its seams. These conditions -- as well as many others such as chronic back pain -- can also be alleviated this way. These are not permanent conditions in many cases although Western medicine often finds no financial incentive in treating them properly.
Anyway, Greenspun seems to have great insight and sensitivity regarding his employees. He will surely put a program in place to prevent stress from harming his crew and his company. Afterall, he has more to lose than anybody if his workers are not healthy and his company folds. I believe it is merciful to dismiss the average programmers who can't keep up before they break down under the pressure. I believe it would be wise to tear the exceptional ones away from their computers for a game of basketball on company time, deadlines be damned.
Overall, aD is probably a great workplace for exceptional people and a terrible place for average ones. This is the best kind of new economy company.
-- Alec Permison, November 6, 2000
Sounds like a well appointed sweatshop to me.
If this is the way you run your company, I'd guess you should be expecting your first employee suicide within the year, if it has not happened already.
Of all the companies I've worked for over the last 17 years, mostly in the Bay Area, those that have come closest to the environment you've described are the only one I know that had employees commit suicide due to burn out. In all three cases they were kids fresh out of college and who had no other work experience to give them a perspective on how well managed companies do not burn out their employees with 70+ hour weeks, week in week out. They did not have a life outside the company so they had nothing to fall back on when the company made unreasonable demands on their time and thereby,literally,worked them to death.
What you describe is not a employer but a very sophisticated form of cult.
When I see companies working long hours for long periods of time I see burn outs producing substandard and ill designed code. Boasting about long work hours is nothing more than a very juvenile form of geek machismo. And like all forms of machismo it can kill or maim those who are seduced it.
If you want a long and productive programming career you have to have a full and active life outside your work, and only work for people who make reasonable demands on your time.
joseph mc connell
-- joseph mc connell, November 6, 2000
I have to second the comments on long hours. While it can easily be argued that it is more profitable and faster to have your programmers put in 80 hour weeks, it is not necessarily to everyones benefit. If you pay a programmer a salary of $100,000 then you are paying him or her at the rate of $50/hour which you can bill to the project. If you convince that same programmer to work 80 hour weeks, then you are paying the programmer at the lower rate of $25/hour and putting $25 an hour into extra profits because you are still charging $50/hour. From an investment perspective, a salaried programmer, putting in long hours offers very poor returns. The principle of "fair exchange" says you should compensate that programmer for investing their spare time in the company. More importantly, as has been pointed out, the cost in personal terms of 80 hour weeks on famlies and relationships is brutal. There is no point in pursuing "worthwhile" projects while harming peoples lives.. kind of a contradiction. One can bring a bit of reality in and schedule a project based on 40 hour weeks.. after all getting to market a month earlier hasn't proved much in the dot.com work other than you can run out of money faster. If one wishes to invest their spare time in work because they are young and single, thats fine, but if they invest their time in their children or spouses or communities, then that should be fine as well. Projects should not be scheduled based on absurd requirements on people.
-- James Ross, November 6, 2000
I'd like to point out a very bad global effect of the current 70+ hour/week workplace, which goes hand in hand with software engineers becoming largely unemployable by age 40 plus or minus:
Where will companies find workers when this brutal reality seeps down to the high school/early college level? Won't most good people, the ones who don't have a real calling to software they can't ignore, avoid getting into the field?
-- Harold Ancell, November 6, 2000
I think a lot of the people opining and singing threnody about the victims of the long and difficult work week are ignoring several of Phil's points, specifically:
Programmer's should feel comfortable having friends and family at the office
The office should provide many more interesting things to do besides work (he gave a nice list)
The office should be more pleasant than the average programmer's home
As a full-time developer in a company that has made half-hearted attempts at these things I can tell you that working 60-65 hours a week comes naturally. I enjoy my work, I'm challenged by those I work with (indirectly), and I can see a direct result between my achievments and the success of my company.
The point here is that Phil is not advocating the sweat shop (quite the opposite - see the Japanese code factory reference); he is advocating a work environment not unlike those that existed two centuries ago. Then you played, loved, learned, and taught in the same place where you made your living.
I will go a step further than Phil and prognosticate that the most productive companies of the future will be entire communities (real not virtual). Of course I'm not the first to think this, but the point is worth recognizing.
As an aside, why is it that we don't recognize that sports superstars put in tons of hours every week to reach their success? If we treated our best programmers like superstars, maybe they would start acting like them.
-- Christopher Atkins, November 6, 2000
It seems to me what Phil is presenting is merely a recipe for economic exploitation rather than management of people. In this world there is no true acceptable bargain other than one that leaves both parties winners. What Phil is presenting is a model that maximizes his gain at the cost of all quality of life for the people he is managing. That model cannot be sustainable. Companies that rely on this sort of management must and will eventually collapse in competition with organizations that treat their employees like people rather than units of productive capacity.
-- eric larson, November 6, 2000
The concerns people express about long hours are quite valid, but I do not believe they are necessarily at odds with the intent of the article. The '70-hour week' is quoted in a fairly simple example, I doubt that is really meant to be an indication of the real hours worked at aD. The example was meant to illustrate the effect of management overhead (Brooks' Mythical Man Month.)
Furthermore, there is much to be said for working intensely on a project so long as there is a commensurate 'downtime' (one of the reasons I quite enjoy project work).
Finally, there is a huge distinction to be made between the sickening sense of obligation to stick around at work as disaster looms and management guilt trips you and hanging around work because you are excited and feel like you are doing something useful and productive. If I get rewarded for the work I do and I like doing it I can make sensible decisions about going out with my friends or working. That is way different to unrewarded looming deadlines.
-- Jeremy Nelson, November 6, 2000
I think what _every_ respondent failed to see is that Phil's 70+ hour week does not mean 52 weeks at 70+ hours a week each year for 40 years, rather that when a project needs it, the programmer does not ask how many hours they've worked at all -- solve the problem now, let the time work itself out. Another aspect that most fail to acknowledge is that programming is not an 'at will' activity such as flipping a hamburger.
A good coder refuses to write bad code; if their mind is not conditioned at a moment to write good code, they'll not write code. IMHO, Phil's approach respects this _feature_ of quality coders/engineers that traditional management fails to accomodate.
-- brent verner, November 6, 2000
There is a lot of good sense and a lot to learn from in this article. However, there's also a lot to dispute. Comment #1:
Suppose we managers at Ars Digita, presumably an example of the point of view in this article, were given an opportunity to hire a guy named Phil Greenspun. He's certainly very smart, experienced in our kind of project, productive, maybe fantastically so, and a terrific communicator, but is he going to give us the hours? He wants to teach a couple of classes at MIT -- that'll probably cost some time. Maybe he can hold them in the comfortable environment of the office -- a good place to bring friends is probably a good place to bring students -- and maybe he can provoke some intense discussions among them so he can write some code while the students learn productively amongst themselves. This guy also likes to travel and take photos, and write extensively about them. Do you suppose he could take pictures of the visiting dogs fighting over pizza scraps in the playroom, or may snap a few shots from the windows of the ocean-view retreat when it's his group's turn to go there?
Not only Greenspun, but other highly qualified and productive people like and need to have pursuits outside the office, benefiting the world at large, their families, and/or themselves. Often, it would be a mistake to reject those people because they're not willing to give up those pursuits to work in a dotcom environment. If having a database-backed website is so urgent all of a sudden, maybe there's been a slipup in the planning stage. If it has to be designed by no more than two people maybe those two people should be given a reasonable deadline, or should agree to crunch hard for awhile in exchange for time off for the photography trip to Italy later, or should receive more than their normal salary so they can make more of their vacations.
Comment #2: Management guides of all sorts are filled with bogus calculations, and this one is no exception. The maxim that 55 hours is twice as productive as 40 depends upon the assumptions that 25 hours is 'wasted' in coordination of effort, and the remaining 15 hours of the first 40 are all useful work. Why should 25 hours of coordination be necessary in a 40-hour week? Maybe 10 would be enough, and worth striving for. But if only 10 hours were 'wasted' in coordination, it would be necessary to work 70 hours to be twice as productive as you would in 40 (but of course the 40 hours would be twice as productive as Ars Digita's 40 hours!) Or maybe 4 hours out of the non-coordination hours are devoted to surfing the web and slashdot (less than 1 hour per day). If you're trying to do twice as much productive work, you don't necessarily need to double the surfing activities, so simply subtracting off the coordination time and doubling what remains isn't right either.
Comment #3: It makes perfect sense that using time at the office for activities marginal or irrelevant to the current projects should not 'count' as productive activity. If I spend an hour every day on the climbing wall, I ought not to go home for the weekend with only 40 hours spent in the office. But if I'd rather spend that hour a day somewhere else, like walking on the beach, and spend my time at the office in more concentrated work, why should this be a black mark. What counts is the productive hours and the results. If the company wants to make it convenient to have leisure and exercise and relaxation in the office environment, fine, but the guy who wants to go home to read his kids a bedtime story, go to a chamber music concert, or even develop a new algorithm for predicting protein folding, might be getting his project done just as well as the guy who's dangling from that nubbin on the climbing wall.
Comment #4: When I referred my wife to this article, she had several comments: -- Vis-a-vis adding dogs, pianos and climbing walls to the programming environment, how about conjugal visits? -- Is this material absolutely serious? ... There are plenty of reaons for adding amenities to a sleep- and exercise-deprived workstyle in which the company has much to gain from long hours and enhanced loyalties. But, I mean, is this Machiavelli? (And was Machiavelli even totally serious?)
-- Jeff Greif, November 6, 2000
There's nothing unhealthy about longer hours if the programmer knows that 40 hours is acceptable and the extra hours are a free choice. Programming is my hobby as well as my career. If work is fun and the workplace is pleasant, I will choose to work more and it will be no different than going home to concentrate on some other hobby. I also have an S.O. and a life, so I will never work for a company which expects me to work more than 40 hours a week.
-- Chris Newman, November 6, 2000
I can see that I struck a chord with the "70-hour" thing... I don't think I got my intent across clearly. Certainly my personal goal is not to see the programmers of the world work 70-hour weeks for 45 years each and then get a gold watch upon retirement. At the same time, if one of my students came back to me four years after graduating from MIT and said "my career pays adequately but it doesn't inspire me and I watch the clock to make sure that I am out the door at 5:01", I'd be a little bit sad. I'd be happy if my student became an inspired watercolor painter, an inspird environmental activist, an inspired fiction author, an inspired cabinetmaker, maybe even an inspired campaigner for George W. Bush (how's that for extreme). As long as he or she were inspired enough by something to give every ounce of energy and effort. Would I expect that level of effort to be kept up for 45 years? For some exceptionally creative people, sure. A lot of Nobel Prize-winning faculty at MIT still work pretty darn hard though they have their tenure and their fame. For others I'd expect them to go through cycles where relaxation, travel, and family become more important. There would be no shame in working for a few years to build something great (be it a software product, reputation as an artist, non-profit org) and then doing something a bit different and less intense for a few years.
(Oh yes, and for the folks who've mentioned RSI... Microsoft Natural Keyboard. It is the only answer!)
-- Philip Greenspun, November 6, 2000
I think the point about learning to work accurately and quickly is a good one. But working at a rapid pace should only happen some of the time, like when you are making a major design change. Also if you work really hard for 9 hours in a day, you are beat and had better go home. There is a contradiction between working quickly and working long hours. If you do both its unlikely you're working smart.
-- scott Plumbleg, November 6, 2000
I noticed that family life is one element that is missing from this description of a professional software programmer. I am a software architect with an internet-related company. I am living a leading-edge professional career with a professional spouse and kids. According to this article, it seems that my life should not exist, or I should feel guilty about living it because I am not in the office long hours during the week or during the weekend.
Answers to these questions would help my understanding:
Can I expect to be an innovative programmer, and still have a family?
Where does balancing my work as an innovative programmer with that of my professional spouse's work fit in?
Where do cub scout meetings, camping, playing soccer, etc. fit into a successful programmer's work week?
Scott McConnell addresses this issue in his book "Debugging the Development Process". He managed the Microsoft Excel project through multiple releases. At one point in his book, he addresses the long work week issue. He says that anyone who works long hours for any length of time ends up taking long lunch breaks, performing errands from the office, and other tasks to catch up with daily life. The net actual work performed is on the order of 30-40 hours per week.
-- James Violette, November 7, 2000
Mr. McGregor's (much earlier) comment on the difference between "punishment" and "negative reinforcement" is flawed.
Negative reinforcement *is* punishment. If I have my toys taken from me for writing bad code, I get mad about my toys. Morale goes down. My code stays bad. If I get flogged continuously while writing bad code, I become upset at being flogged. Morale goes down. My code stays bad.
After all, even if I get my toys back or the flogging stopped, my environment has not significantly improved from its base condition. I signed up knowing that I get toys and that flogging is illegal in a work environment. Most companies I could work for are likely to take away toys on a whim, or start flogging should it become legal. Either way, such an act brings my environment closer to or below the base condition.
Adding toys I want (as opposed to toys in general) or having people I hate get flogged would be something I'd work harder to get. I'd work harder if I knew that repetitive, redundant paperwork would go away. I'd work harder if I knew that I would be paid better *at the end of this project phase* and not sometime in the far future. I'd work better (not just harder) knowing that others would enjoy my code (train me to write code worth enjoying).
I can endure suffering. But I cannot work well while straining my endurance. Seventy-hour weeks? Sure. Give me enormous benefits. Forty hour weeks? Sure. Make sure I'm in an environment that lets me work to my best capacity. In fact, I want that environment for the seventy-hour weeks, too.
And that's all I have to say about that.
-- Zach Collins, November 7, 2000
I think I have to agree with most of the comments about long hours and such. I am currently a junior computer science major at Texas A&M University, and I have had 2 internships, and a research grant (at TAMU). My experience so far has been that I like to work longer than 8 hours when I don't really have anything else better to do, but 70+ hours wouldn't be good. MAYBE 55. As a young single guy who loves computers and technology and electronics and math, etc., I like to accomplish things at work. However, I also like to go back to my place and learn new stuff, so I can accomplish more. If I don't get home until 7-8 pm, I don't really have adequate time to spend with my family or friends, or doing anything that I love to do outside of work. That kind of thing would just make me resent my job, and look for another one. And remember: all this from the perspective of a guy who the author says would be happy to work 70+ hours.
-- Ben Collins, November 7, 2000
The best way to alienate women from IT is to continue spreading this myth about the 70 hour weeks. The only people who truly believe that they produce better results by working more are people that
don't have a life away from the machine
aren't able to judge the quality of their own work
Women don't usually fall into either of these categories! Women generally have a much more balanced life, understand the need to do basic things in life, i.e. grocery shopping, cooking, dishes, hanging out with friends, hobbies and yes, raising their kids.
The funny thing about a balanced lifestyle is that although one works less, the work one does is better. And because one is able to go home in the evening (at 6:00!), one has time to reflect upon the work that one has done with some perspective. And consider what goals one has for the next day. And if the programming from that day was worth anything.
I suspect that the reason that I encounter so much buggy, lame code in the ACS is that the code was developed exactly the way you are suggesting in your article.
-- Sarah Arnold, November 7, 2000
This article is seriously flawed.
Written in a goading style, it ignores much of the ongoing research into software productivity, (See Capers Jones, Barry Boehm, Steve Mc Connell, et al.). The recurring truth is that in successful software projects, a mere 20% of the effort is spent in coding. This article pretends that coding is the only thing that matters.
This is very flattering to those who code, but ignores reality. Coders may read this and say, "Yeah, finally someone is speaking for us!" But anyone who has occasionally looked up from the monitor to take a look around the rest of the office knows that this view is extremely myopic. Programmers aren't the only people in the organization. And any software company that cannot make use of the average programmer while slavishly worshiping and abetting the whims of the often overrated and inconsistent superstar is bound to fail in the long run. The superstar will sometimes do something brilliant that saves everyone's ass. But planning for this, and staking the company on such erratic behavior is just plain stupid.
Rather, the key to consistent (rather than haphazard) software success is planning, coordination, communication, and perseverance. To suggest otherwise is special pleading and vanity of the sort that leads to hubris. And the gods always punish hubris.
Fred Williams
-- Fred Williams, November 7, 2000
I see a lot of complaining about the 70+ hour work week issue. I think most of the people here miss the point of what "great" programmer means. You can be one of the best writers in the world but if you write only a paragraph a day you'll never be "great". You may technically be one of the best artists of your era but if you don't immerse yourself in it day and night you'll never be "great".
Sorry, you may be a genius problem solver and coder but part of being a "great" is giving yourself over to the art. It DOES mean giving up your free time, it DOES mean maybe not having children, it DOES mean maybe burning out, it DOES mean sleepless nights telnet'ing in from home to work on the problem you just left. Being a programmer at the "great" level, building a major system with the purity of vision you need to be "great" means no distractions and getting the core of the code down before the "Man(ager) from Porlock" comes along to snatch your vision away.
Putting it more succintly, arsdigita gratia artdigitas =)
-- Mark Mills, November 7, 2000
Many of my comments have already been said. I would also suggest to Phil that his RSI suggestion is much too flip. Sure, Microsoft natural keyboard. But even there people with serious RSI have problems.
But that's relatively minor. I think that you should take a look at the research into brain physiology and how that relates to attention and time spent on tasks. If you consult with people in neurophysiology and look around you will find out that the kind of hyper stimulation that you are suggesting leads to brain damage. It causes shrinkage of the brain tissues that deal with the correlation of data when prolonged. One can meet these people, the veterans of startups and places like the Redmond offices of Microsoft. They are the ones who know a great deal, but can no longer respond with the answer quickly. Many can hardly function at all without copious amounts of coffee.
My personal observation is that I think that such behavior when prolonged leads to other kinds of neurophysiological damage as well. I think that further research will document this. The behavior I am referring to is that of spending too much time concentrated on one task. Lack of sleep also contributes, as does levels of adrenalin. When coupled with the commonly poor nutrition of the "programmer lifestyle" you describe, all of this causes serious problems over time.
There is also the research of a neurologist at, I believe it is Harvard Medical School, though I may be mistaken, into the reasons for the greater shrinkage of the frontal lobes in males versus females by the time middle age is reached. He believes that this is related to the fact that males tend to use the same areas of the brain when in relaxation as they do when they are working. Whereas females show a slowing of metabolism in the frontal lobes when they are asked to relax. He is studying the 10% of the male population that does not experience frontal lobe shrinkage by the age of 50. (By the age of 50 most men have smaller frontal lobes than most women.)
Please note that the lifestyle and management methods you are advocating is, according to research, pretty much guaranteed to cause brain damage, and quite rapidly - just a matter of 5 years or so before significant effects can be measured. I am not being facetious here, it is quite a serious matter.
-- Brian Hanley, November 7, 2000
It's interesting that most of the people here appear to be US based.
As someone that now lives in regional Australia, But has spent most of my professional life developing software in New Zealand many of Phils ideas sound lovely but are unobtainable in these smaller economies.
A office decked out with playrooms, beanbags, Air Hockey etc would be great but outside of a dot com heaven like Boston or Silicon Valley it just is not going to happen.
Mine is a case in point, I'm working on a package for ACS 4.0 to help with News Media publishing (I'm a developer for a newspaper), I'm also the IT Manager, so yep I get to pull the 70+ hour weeks.
What I do have is the ability to go grab my dog and tube down the river at lunchtime if I want or jump on my ducati and go for a fang through the hills.
The message in Phils article is to treat good programmers like you would any artisan, accept they will have their idiosyncracies and provide an environment that allows that. Their own ego will discipline them into giving you a good return on your investment.
Sticking them on a 9-5 in Cubicle hell will just take the joy out of the art and you'll get crap code.
So do I provide people anything else other than a good screen comfortable office, no I don't. But if they want to start work at 2 in the morning (I don't care) they spend half the day surfing slashdot or reading Code Complete or trying a new language (I don't care). If I only loosly monitor these people I'll get far more out of them than if I MANAGE them.
Now if only I could bring my dog into the office, that would be cool, although a labrador that likes to chew could do serious damage to the fibre comms cabinet :)
Maybe when I've finished newsflow (the News Story ACS4 package) Arsdigita will open a office in Australia or NZ and I'll ship off my resume, until then the dog stays at home :(
-- Roger Lockerbie, November 7, 2000
from
http://www.cultinformation.org.uk/faq.html#cult
My comments in [].
What is a Cult?
Every cult can be defined as a group having all of the following five characteristics: 1. It uses psychological coercion to recruit, indoctrinate and retain its members
[for example trying to convince the 'employees' never to go home by making the office nicer than home, indirectly forbids contact with non company employees by keeping them in the office during all potentially social events, holidays outside work discouraged.]
2. It forms an elitist totalitarian society. [average people will face rejection at the whim of the employer, possibly being taken aside for special care to make them a good progammer.]
3. Its founder leader is self-appointed, dogmatic, messianic, not accountable and has charisma. [the founder is not accountable and self appointed.]
4. It believes 'the end justifies the means' in order to solicit funds recruit people. [each person that leaves a 6pm should be found a project to *make* them stay. Pay is increased, goodies are given away to encourage them to stay for as long as possible. No asking if they *want* to stay. ]
5. Its wealth does not benefit its members or society. [since they don't have a chance of ever getting to spend it]
All in all, Greenspuns 'ideal office' probably isn't a cult. However, it's far far too close to one to make me submit to brain washing. Sorry, I mean work for him.
-- Pete Stevens, November 7, 2000
PG writes: "Oh yes, and for the folks who've mentioned RSI... Microsoft Natural Keyboard. It is the only answer!"
Not only is that not "the only answer", suggesting that there is such an "answer" to RSI is a gross oversimplification of the problem.
Suggested reading: http://www.amazon.com/exec/obidos/ASIN/0471595330/
-- John Siracusa, November 7, 2000
1. I disagree that an outstanding programmer is 10 times as productive as a good programmer. In my experience it is more like 16 times as productive.
2. As far as people having an inflated idea as to their value ... I just completed a round of interviewing Senior DBA candidates. It was a frustrating experience since all but one were barely qualified to be a junior DBA. For example, one candidate who demonstrated a complete lack of understanding concepts is currently making 85K. This person was out looking for a job because his present position doesn't pay enough :-(
3. As far as long hours go ... I think one responsibility of management is to go in and chase the developers out of the place at least once a week in order to protect them from burnout. Truly outstanding programmers (and engineers) are self-motivated and if they are interested minor things like working hours, good eating habits, clothing changes, and bathing tend to get lost in the shuffle.
4. Open offices can be great! One project I worked on had four developers sharing a 30 x 30 space. We each had a desk facing a wall and in the middle we had a table. This gave us the privacy we needed when doing individual work while it greatly simplified communication.
-- Jerry Gitomer, November 7, 2000
In my experience, someone who needs to work their staff 70 hours a week is a bad manager.
Probably never heard of contingency, planning, resourcing, staff turnover, empathy or respect.
-- John Smith, November 7, 2000
I am glad to see the issue of overwork being brought out. While I agree that having a good work environment that caters to programmers is good for everyone, the motive to use programmers as a means to extract extra profits is dubious. As I mentioned before, a salary means you are paid for 2000 hours a year more or less, not 4000 hours. Independent contractors know this and bill for every hour, but salaried employees who put in 70 hour weeks to build a commercial website are just fooling themselves. I worked in the aerospace industry on critical projects during the Cold War in 70s and 80s and we rarely put in more than 50 hours/week except in emergencies and that was a lot more worthwhile than a Sales Intranet site. Philip said that the goal is to produce more Richard Stallman's etc which is admirable. I have noticed that most of these huge contributers to CS had day jobs which did not demand more than 40 hours so that they could spend their spare time working on concepts and software (mostly at universities where they also had free access to computing resources). Like many engineers I probably spend 70 hours a week at least on my profession and have invested in significant computer systems, however only 40-50 hours are directly related to my job. The other hours are spend playing, exploring, reading, coding etc as I see fit. This is where I learn new things and explore new ideas that I can put to use in the future. As an example of the foolishness of working long hours without compensation, friends of mine worked at a dot.com which seemed very solid and repeatedly put in long weeks and weekends etc to meet arbitrary deadlines and were encouraged much as Philip suggested. The investors then decided to change direction and most of the staff were laid off without warning. The management of course managed to retain their jobs and snag huge bonuses
-- James Ross, November 7, 2000
Web site development doesn't require quality because it produces disposable software. Web applications written today will be trashed next year. This article is consistent with achieving rapid deployment of temporary (i.e. no need to worry about maintenance) software.
I have never met a software wizard ('productive programmer' in the article's terms) who could produce quality, long lasting software. Thats why it doesn't matter that the web world is dominated by productive programmers. Not for now, anyway.
The best software I have encountered has been produced by dedicated people who go home at 5:30 and start work the next day revitalised.
I have worked in Cambridge MA alongside ex MIT 80 hour weekers and I have worked in Europe alongside 40 hour weekers. The productivity was about the same.
I would like to hear from organisations that develop software products with a lifespan of more than two years. Is the programmer the important element? I think not. They are just the factory floor workers adding in their valuable piece. The team makes a quality product. Designers design, analysts analyse, managers manage and sales and marketing people make it successful.
-- Neil Burnett, November 7, 2000
It seems everyone responding is in the class of people beyond "just graduated". I recently graduated from a four year university and am currently working at a dotcom company. For me, I see it as an alternative to school. It allows me to push myself harder, learn faster, and get a jump on my financial future. Most importantly, the work is more rewarding and I deal with more intelligent people.
The article is aimed at managing startup companies. It's not for managing people who work at the large software companies. Startups generally don't have their own day care centers, gyms, pools, etc. A startup only works if you don't carry any extra baggage(i.e. people looking for a free ride). People working startups don't want those things (avoid them, actually). They work for one or more of the following reasons: money, inspiration, education, and freedom(yes, freedom). Freedom meaning nobody tracks your time, just your work. If you leave at 2 in the afternoon and come back at 11pm, it's up to you. A person working at a large company is there for: job security, retirement, benefits, and a paycheck. The goals are quite different.
Work is my entire life. Would my life be better spent if I joined a frat and drank myself to oblivion every weekend...I doubt it. We're purists: the type of people that think G. W. Bush's DUI makes all the difference in the world. For someone to be great at something, it is their life...no more, no less. His DUI tells me being president has not been his life's goal.
Jeremy H.
-- Jeremy Hughes, November 7, 2000
The key is finding the right sort of people to work this scheme with. Programmers/Hackers work in bursts. When there's an interesting or challenging problem, they are willing to work those insane hours putting the whole thing together. It's fun to spend two weeks holed up in the office with friends, working on a big, cool solution to a neat problem. This is not sustainable though in general. Eventually, everyone (even hackers) needs some downtime. The only way it can work is if you can find the kind of people who will competely forge their own social group around their co-workers. Then work is their social life, and they can work those 100 hour weeks without quality of life suffering. Depending on having that kind of person, while trying to grow your company past 40-50 people who share the same vision is the real trick.
-- Rob Meyer, November 7, 2000
Jeremy Hughes' comments are spot on. The practices and principles in this article may apply to start up companies and dot coms but are very difficult to apply once a company moves beyond this point. What start up companies and dot coms have in common are relatively simple products. Once a product matures and its customer base broadens what a product manager needs is those who can create the right product, in the right way that will meet customer expectations. This requires know-how and experience. Far more than a gun programmer that will work 80 hours a week to meet a deadline, the product manager needs an experienced software engineer who understands the market, good design, risk management and mentoring of others. This person is usually not in their twenties, wants a life outside of work and is willing to hang in there for the longer term.
-- Craig Ashley, November 7, 2000
Excellant article with an inaccurate title. More correct is "Managing a Software Sweatshop." And what's wrong with working in a sweatshop? It robs you of your humanity and you become a disfunctional member of society. Your personal relationships, if you have any, breakdown. You do not contribute time to your child's school or extra-curricular activities. You do not contribute to your church's work -- you might not even go to church. And all this distortion of the employee's personal life is to make the business owner and his inner-circle very rich. It's actually a great experience for a short while, but it is unhealthy for people in the long run.
-- Robert Canright, November 8, 2000
You know, if Greenspun here is really serious about wanting to get programmers to work these really long hours and if he is honest about how much it improves the profitability of a company, then I wonder why he doesn't pay by the hour. The most direct way to reward someone for the hours they put in is to pay them for each and every hour they put in. Freshman econ kinda stuff there. You pay them a competitive wage at 40 hours per week, and then every hour over that, they get the same rate at time and a half overtime, as the law requires. If it is so massively profitable to have programmers work those hours, there should be PLENTY of cash to pay the programmers for working those hours, right? So the more they work, the more money they make. If instead, the management is trying to get rich on the backs of the employees, they'd pay a flat rate and then try to work the employees as much as possible. Why should those extra hours be free? You want it, you have to pay a premium. I'd even argue that there should be an increasing scale, so hours over 60, for instance, should perhaps be paid double, then hours over 80 are paid 2.5, and so on for every 20 hours more in a week. That extra time is extremely stressful and hard on one's outside life, and so the cost goes up. My personal belief is that if Greenspun DOESN'T do something like this, then his whole article is BS because he's not backing up his rhetoric with his money.
-- D Goodkin, November 9, 2000
Remember folks, this article is about how to put out products cheaply and in the shortest time possible (which usually go hand-in-hand but not always) to make the most money for the company. That's why "Managing" is in the title. It is not about how to create the highest quality products. It is not about how to retain employees. It is just about making money. In certain fields of programming this is a viable solution for the short-term. Trying to pass it off as "for your own good" is just the rhetoric-spin that people always use when trying to get you to do something that is not in your best interests.
-- Jeffrey Kabbe, November 9, 2000
Is there anything wrong with working circa 70hpw? That's probably a bit more than I do (yes, I have a family). However, I'm not sure about trying to *code* for that kind of length of time. If you can code for even an afternoon a day then you're productive. I'll let you figure what an afternoon is.
I do think it's a mistake to measure hours: that's just an accounting convenience to determine client billables. Billable hours are a largely sensible business practice, because they're easy to pad and have the seeming forms of accountability and professionality. Closed source used to be a largely sensible business practice as well.
There's a difference between billing hours and getting things done (but we all know that). Hence I disagree with another poster who said that ArsDigita should pay by the hour. Since being paid by the Things Got Done maybe difficult to implement in a general way, a salary seems a reasonable compromise. But in terms of evaluating your ability to work *hpw are shockingly useless and almost certainly misleading. What does the fact you've worked 90 hours this week state about what you accomplished? What does ArsDigita's mission statement mean in terms of hpw? As computer scientists like to say, these things are orthogonal.
Anyway, all you really need to know is how much you got done last week/month/year. Since that's roughly how much you'll get done next week/month/year. If you're not happy with that amount of got done, then you need reflect on your life in order to change things.
Also, I'm surprised at no mention of Extreme Programming so far. It's supposed to be controversial, so if you liked this page you'll probably like this book: Extreme Programming Explained (also a good of example of a book that is no longer than it should be).
-- Bill de hOra, November 12, 2000
Oh yeah, some responses:
Remember what Fred Brooks said in The Mythical Man-Month: high quality systems must be architected by no more than two people.
-Don't architect your systems. Fred Brooks was right a long time ago, not now. Software systems that are used are never finished: therefor static architecture of software is a mistake. Don't bother designing at all.
Your business success will depend on the extent to which programmers essentially live at your office.
-You're confusing physical and mental presence.
How does one create a good programmer?
Make her work with a great programmer.
What attracts good programmers? Traditionally the best programmers seek the most challenging problems. They want to work in an organization that is trying to build something important.
-They also want to work with minimal interference. Let programmers program.
If you see one of your best people walking out the door at 6:00 pm, try to think why you haven't challenged that person with an interesting project. If you see one of your average programmers walking out the door at 6:00 pm, recognize that this person is not developing into a good programmer.
-Early birds aren't good programmers?
Yet managers who are spending a portion of their time designing software or writing documentation are at risk of neglecting their duties to review subordinates' work.
-don't document and don't design. Also, conserve managers.
Our solution is to decouple responsibility for review from responsibility for scheduling review. We use administrative assistants to ensure that each manager is scheduled to look at every subordinate's work at least once per week, more frequently in the case of junior employees.
-if reviewing is good, constantly review. Use programmers to review programmers.
Software engineering companies will tend to have a fairly flat distribution of intelligence. The 22-year-old Stanford CS punk that was just hired will be just as smart as the 30-year-old lead engineer who will be just as smart as the 40-year-old CEO. Within a company's technical team, the raw IQ differences are even smaller.
-if we know that there is a least 10-1 difference between great coders and everyone else, then we know that IQ has little to do with it.
positive reinforcement is more effective than negative reinforcement
does not easily sit with:
But at the end of the day nobody should be confused as to who is providing leadership. There is an irreducible amount of Engineer A imposing his or her design on Engineer B. This can lead to some harsh-sounding words and bruised feelings.
-In discussing the workplace, you neglect to mention psychological comfort.
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. -then: learn half as much new technology (if technology moves so fast, half of it won't be worth learning anyway), halve coordination with other programmers, halve documentation time, halve leadership activity time, halve attempts made to comprehend complex systems. Under this reduction a programmer working a 40hr week will be almost twice as productive as one who doesn't. Under this reduction a person who works a 55hr week will be roughly 50% as productive again as one who works a 40hr week. One will actually need to work just under a 70hr week to be twice as productive as someone who halfs their non-code activities. It's obviously more efficient to perform a self-motivated business process reengineerment than double time spent coding.
-- Bill de hOra, November 12, 2000
Programmers dread elaborate process, endless meetings, and layers of marketing approval before a product can be shipped. Ideally it would be possible to conceive a product on Friday evening, set up the development environment Friday night, write code on Saturday and Sunday, test on Sunday night, and ship on Monday morning.
An excellent article that generated a lot of discussion about productivity, work hours and defining "great programmers". However I was shocked to see this gem pass everyone by. In the above scenario even cutting edge companies with great programmers are going to be shipping crap out the door because they neglected to put the hours in testing it.
-- Mark Pawson, November 14, 2000
It's amazing so many people criticizing the 70 or 80 work week.
You will probably work for 10 or 20 hrs doing something that is very very boring to you, as a programmer it might be : debugging a script you didn't write, sitting at a weekly meeting , answering email , or anything else you may find annoying .
And the way I see it , the other +50 +80 hrs has to be spent doing something that REALLY REALLY appeals to YOU , if it doesn't, the 70-80 hour work weeks will seem like a living hell.
In company or corporation terms, it doesn't matter how good the culture or spiel is, it may offer you whatever benefits,money,work environment,growth, or even the CHAIRS THEY USE ! in the end if your in it for the: I am working at X company and WE are developing blah,blah,stock options...
Notice the WE, I think there is a special distinction in the WE..... The extremly common BANDWAGON TEAM WORK environment: WE are working in a gizillion dollar project, WE are developing a HOT new java API.
The difference is that the company really doesn't gives a rat's a** in the end, they want you to get the work done!. If YOU REALLY dont like it, you will not only stick out the typical 10-20 hrs doing the annoying work,your whole 70-80 hours will be the same, your 30 minutes of glory will be when you brag to non-coworkers the HOT new API or stock-option's.
The people who are working the 70-80 hr weeks probably do believe in their job, the "team work (smart people attract smart people)" and "work environment (beach houses, ski houses ) " are all major benefits. But in the end , they must posses a "self-interest" in what they are doing. When the dust settles and you see the 90 grueling hours, wise-a** managers, no 5 week vacations , where will you be left ?. I wonder how much time the REAL employees spend at the ski-houses, beach-houses or whatever fun place. I wouldn't doubt if these things had a sign saying: "FOR EXCLUSIVE USE OF POTENTIAL HIRES"
My brief experience.
I read this spiel , excellent, "Home Study Program" , $10,000 signing bonus!! thats for me I said.
My friends: your crazy!, 2 months working for free ! . my naivite on the $10,000 bonus blinded me at the moment, but I knew it would be worth it.... so 2 months passed, and I turned in the problem sets:
Answer : We have a hold on hiring at the moment, please check back in October.
My sub-conscious: I knew it , my friends where right !!.
But wait, its a great system. My self-interest or possibly "naivite" pushed me to do more, lets learn Oracle from the ground up lets go for Oracle Certification, lets do something radical (may be even stupid) with AOLServer an AOLServer Driver with JDBC , for sure the Arsdigita guys will like this, BUT lets keep a backup project just in case , you never know!.
Sure enough this October came, with all the hard work I thought I was a shoo-in:
Answer : mmmmmmmmhhhhhhhhh,we are looking for project managers and QA engineers at this moment.
Great, just great, 6 months down the pipe, right ? WRONG!
From the beginning I (sort of!) acknowledged that if it didn't turn out , what I was learning would pay off.
Am I mad because Arsdigita gave me the cold shoulder ?
I am greatful with Arsdigita for offering such a system for FREE, for the cold-shoulder ? , its what I could have expected from any company be it Sun,Sapient or whatever other company out there.....
Remember that a companies work is to TAP (exploit!) its workforce knowledge,they know some guy is possibly worth $150,000 a year , and another $250,000 a year, they MANAGE THE PROGRAMMERS so they will be worth $600,000.
They reap the benfits two ways : From the $600,000, they pay the employees a little less than their worth say $80,000 (vs. the $150,000 ) and $120,000 (vs. the $250,000), and MANAGE the chemistry (a.k.a. "added value"), total net gain for the company: $230,000 (yes, the $200,000 not accounted for goes to the MANAGER and $100,000 for your Insurance,Skihouses,and pinball machines).
Is there a problem ? Absolutly not, as a matter of fact its perfect , everyone is happy !.
Just as a final remark, when you do your job try to focus "inwards" on your SKILLS. Uncertainty is the only certainty ! , and your skills are probably the only CONSTANT you have.
As someone mentioned in a previous post, "independant consultants know what they are worth, they charge by the hour"....but until the time comes when everyone of us knows "what they are worth", companies will still be TAPPING (exploiting!) away and MANAGING PROGRAMMERS.
-- Daniel Rubio, November 18, 2000
Phil mentions (and links to) a study that shows how people are unaware of their own incompetance. I would add what I feel is an important corrolary to this: that people highly competent in one field are often totally incompetent in a different field, but think that they are "smart" and therefore competent in the other field as well. For example, Bill Gates is a world class expert at getting rich, but he's totally incompetent in the area of diet and exercise, as evidenced by the pot-belly he displayed on the cover of a recent issue of Business Week. However, if you were to ask Bill about it, I bet he would think he's very competent. I think so because he invests in biotech companies, and he could tell you a lot about genetically modified food and whatnot (he wrote an article about GM foods for Time magazine).
Another point related to this: you should never trust a person's self-assesment of any skill in a job interview!
How many times do people ask, "How would you rate your C++ skill" (or whatever) in job interviews? Don't ask questions like this. The answers are completely useless, as both the competent and incompetent will give the same answers. We routinely find that people interviewing for programming jobs lack the skills they claim to have on their resumes. We can expose this by asking them to write the code to solve a problem that lies entirely within the domain that they claim to understand. Something like "query the database for a list of names, and generate the HTML to put it in a listbox." If the applicant claims to understand both the database and web programming technology, they should be able to do this. It's amazing how many people can't.
-- Wayne Radinsky, November 23, 2000
> If a product is being developed rapidly
I think you misspelled
"If a project is poorly planned and badly executed"
Hope this helps.
Sean.
p.s. Any project where "average" programmers are having to spend "nearly their entire work day reading and understanding new code" is in serious trouble.
-- Sean Sollé, November 23, 2000
Everyone's covered the long hours thing except that I wanted to add, since project planning is rough and surprises do happen, even planning on the basis of 40-45 hour weeks is a bad idea. I suggest that projects should be planned and scheduled on the assumption of 30 hours/week per person. Not even 35. The usual overhead and red tape and waste that always creeps in will easily expand this to 35-40, and the crises that happen because the design is flawed or the user changes their mind or whatever will expand this to 40-45, 50 at worst case, which is tolerable for short spurts. The projects should be planned on the basis of 30 hours/week and people should wind up working 35-40 hours/week on the average. This way you'll get everyone's best hours and therefore their best work, and it also helps morale. And since I read somewhere that projects should be broken up into small enough tasks that could be done in about a week, that means about 20-30 hours for each task.
Routine 50-70 hour weeks are a sign of bad management. Sure, I routinely work 60-70 hour weeks but that's mostly due to the incredible resource constraints of growing a business on a shoestring in the face of too many of the usual obstacles to list here. But I'll also admit that my own management skills could use more improvement. And there's no way I could work these hours at all every week if it was mostly outside my home office.
Those who insist that it's not economically feasible to plan for less than 40 hours/week may appear to have a point in the case of travel expenses for contractors brought in from out of town, since the travel expenses are by day and by flight rather than by hour, but again, I'd suggest that being so insistent on on-site work and other criteria that one would bring in out of town talent may itself be questionable management, at least in some cases. If brokers and clients would stop hiding the travel expenses in a higher rate and show them separately, the economics could become more evident, but regardless, it's questionable except for very short, specialized projects.
Part of the reason that the best programmers are so much better than the worst is that they have good integration of both halves of the mind, as they say. It takes both intelligence and intuition to be good at highly technical and highly creative work like this. This is a major reason that micromanaged PHB-ridden environments are counterproductive. Intelligence, intuition, and especially the combination of both are easily tired and burned out if not refreshed by a well-balanced lifestyle. This is partly why it seems that many of the best programmers are also into music, art, fantasy role-playing games, underrepresented religious and/or political views, and offbeat hobbies. All work and no play makes not only the people but also the work itself suffer as a result.
Robert M. Pritchett, President - RMP Consulting Partners LLC - member ICCA
Quality means doing it right the first time
-- Robert M. Pritchett, December 19, 2000
Regarding employee's work hours:
I agree with the author, someone who works for 65/hours will be close to twice as productive as someone who works 40 hours, assuming that he is working for 65 hours per week by choice. If the workplace is more attractive than the home, it is locical that the employee would do this. The ideal programer will enjoy programing, and the ideal programers for a large project will enjoy working for 65+ hours / week while they are doing the project. My view for a sucessful company is one that highers all good programers available to them, and assigns smaller projects to those who wish to work less, while assigning large projects to small groups of 2-4 commited programers who want to work for 65+ hours / week, and then gives them optional large breaks afterwords.
-- klyde beattie, December 20, 2000
The author seems to believe that the only way to deliver a project on time is to work 60/70 hour weeks. Amazingly enough, it never occurs to him that perhaps people wouldn't have to work 60 hours a week if deadlines were realistic with the requirements and best practices, and projects were well-managed.
All the projects I've ever seen have gone over, even with programmers working overtime, because of poor management and ridiculous deliverable expectations.
-- Peter Risser, January 18, 2001
To respond to the comment above... I never said that the only way to deliver a project on time was to work more than 40 hours per week. If your project is installing Microsoft Exchange, maybe you can get it done in two hours. I was writing about young people building careers. If you just want to do what someone else tells you to do, I guess in 40 hours/week you can be pretty productive. If you want to make a contribution to the world significant enough that someone will remember your name, you probably need to spend some time (a) looking at what others are doing and figuring out something worthwhile and innovative to do, and (b) writing up what you did and demonstrating it to other people. These activities are going to take some extra time. That's why you don't recognize the names of too many engineers who've worked 9-5 M-F their whole lives. Maybe they designed a bolt on a landing gear on a Lockheed plane in the late 1960s. They were productive, in the sense that if they hadn't come to work someone else would have had to work a bit harder. But then the recession came and half the aerospace engineers were never able to find engineering work again. The guy who never built a personal reputation was then working as a greeter at Six Flags for $2.75 per hour.
Imagine if Microsoft, Oracle, Sun, and RedHat made products that simply worked and worked simply. All of a sudden half the people in IT would be out of a job. My article is about building an organization where all of the tech people would still be employable after such a shakeout.
-- Philip Greenspun, February 16, 2001
Greenspun's (previous?) response about people not remembering your name if you work 9-5 is not just defensive, but so patently stupid as to be offensive as well. I'd imagine there are tens of thousands of 60+ hour engineers out there--habitually, year after year--and I'd imagine none of you out there can name more than a few of them. They're in pretty much the same boat as the 35 hour engineers, except now that they've been laid off they have no families or friends to fall back on.
Philip's brand of reasoning was trashed pretty thoroughly in Crime_and_Punishment, but knowing how that worthless engie school in Mass treats the humanities, I'd guess we can't expect insight.
A brilliant idea may inspire you to work long hours (if you're too disorganized or otherwise committed to get them built in short hours), but working long hours proves nothing about your ideas (only about your priorities).
Philip's is a clear statement of the yuppie ethic: it doesn't matter whether you produce something of value, the important thing is to _take_credit_ for producing something of value. It's no wonder his fallback position is Professor.
Given his evident disdain for competent craftsmanship, it's no surprise his grandiose schemes end in disarray; and given his ethic it's no surprise this turns out to be someone else's fault.
-- David Zink, May 29, 2001
Related Links
Discussion of this article on slashdot- Discussion of this article on slashdot (contributed by Joel Londenberg)
How Software Companies Die- Orson Scott Card on what happens when the above advice is ignored. (contributed by David Eison)
Portland Pattern Repository discussion on the value of working OverTime- "That said, it is clear that the overall productivity goes down with LongHourWeeks." (contributed by Charles Miller)
They Write the Right Stuff- The group that writes the controling software for the space shuttle launch does it extremely well, and in 40 hour weeks. (contributed by Ben Heavner)
How to Manage Geeks- Eric Schmidt (CEO of Novell) gives a nine-point tutorial on managing geeks. (contributed by Kaushik Sridharan)
Whaddaya mean, you can't find programmers?- Another take on making a nice place to work for programmers. No mention of how many hours they work though. (contributed by Dave Bauer)
A Harsh Reality- Common industry practices which are intended to standardize and improve software quality often make things worse. (contributed by Robert M. Pritchett)
Comments