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