Slashdot Mirror

Greenspun is a very cool guy. His book Philip and Alex's guide to web publishing is awesome and can be read online for free.

He was once quoted as saying something like,

-- Who needs funding, we have profits --

They also run arfdigita a non-profit animal rights group. But unfortunately something went wrong somewhere.

There open-acs platform is awesome. It provides all kind great functionality: bulletin boards, user permissions, site and ad tracking. But arsdigita changed their buisness plan to sell closed-source modules for the platform. It seems like a bit of a scam.

This page at the ArsDigita site still lists Greenspun as chairman. I guess it's too much for a Web content company to correctly list its chairman in its own Web content?-)

I guess one of the 29 people they laid off was the guy that updates their website. :-)

http://news.cnet.com/news/0-1003-202-5522429.html

"ArsDigita, an e-commerce company in the midst of layoffs and a major product overhaul, is bucking the trend of comrades selling open-source software.... The company laid off 29 employees in the last week, and the company's founder and former chairman, Philip Greenspun, has left to pursue other interests ..."

Note that the story quotes a current executive as saying Greenspun's departure was voluntary; Greenspun says, "last fall ... my services as a full-time employee of ArsDigita Corporation became unwanted."

This page at the ArsDigita site still lists Greenspun as chairman. I guess it's too much for a Web content company to correctly list its chairman in its own Web content?-)

...with something more to your liking:

Ximian is the leading provider of flexible, open source desktop software and solutions.

The Ximian GNOME System provides a flexible platform to develop applications uniting people, partners and processes. Ximian provides organizations with tools for content management, commerce, collaboration, personalization, and marketing and analysis. Fully integrated through a single data model to ensure consistency across all business processes, Ximian enables customers to capitalize on the benefits of a desktop environment.

Ximian also offers professional services that can develop your business applications. Learn how Hewlett Packard and Leading Linux Distributions are working with Ximian.

Note: This is a shameless parody of... Some Site, and is not a statement from Ximian, or any other company. How's that? Is that silly enough?

I like the penguin. =^_^= It's cute. Bonobo are cool.

Uptime periodically requests a page from your server. If the site is unreachable, Uptime sends you email. Uptime will continue checking your site. When it becomes reachable again, Uptime will send you one more message.

If you wish to be beeped by Uptime, then you need only subscribe to a beeper service that has an email gateway. You can give Uptime a custom subject line or message body if your beeping service needs a specially formatted message.

What's the period? Right now, the average user's server gets queried every 15 minutes. We have "gold" and "silver" users who get queried every two or five minutes. These are generally friends of ours or people who help support this site in some way.

Uptime periodically requests a page from your server. If the site is unreachable, Uptime sends you email. Uptime will continue checking your site. When it becomes reachable again, Uptime will send you one more message.

If you wish to be beeped by Uptime, then you need only subscribe to a beeper service that has an email gateway. You can give Uptime a custom subject line or message body if your beeping service needs a specially formatted message.

What's the period? Right now, the average user's server gets queried every 15 minutes. We have "gold" and "silver" users who get queried every two or five minutes. These are generally friends of ours or people who help support this site in some way.

As I have hinted, I think that companies such as GE will start to put Internet interfaces into their appliances as soon as about 20 percent of American households are wired for full-time Internet, for example with cable modems (see Chapter 6). But they won't do it because they think it is cool for your GE fridge to talk to your Whirlpool dishwasher. They'll do it because it will cut the cost of tech support for them. Instead of paying someone to wait on the 800 line while you poke around with your head underneath the fridge looking for the serial number, they'll want to ping your fridge across the Internet and find out the model, its current temperature, and whether there are any compressor failures.

Oh yes, for those of you who are tools-obsessed, you'll be pleased to know that the new curriculum is tools-neutral. When we started out, none of our students came in with experience building Web apps and none had used RDBMSes. But now a student might have had a summer job using PostgreSQL/mod_perl/Apache. I don't want to look at his Perl code but I'm not going to tell him he can't use his familiar tools to complete 6.916. If another student is jazzed up about Microsoft .NET and she wants to use C#, VB, and ASP.NET, more power to her. We'll look at her data model, page flow, and what the application accomplishes.

This is sort of the same progression as has been followed by ACS. When we started packaging up our apps we said "Wouldn't it be nice to have three versions, one for Oracle/AOLserver, one with a Microsoft Active Server Pages presentation layer, and one with a JSP presentation layer". But we were only five part-time programmers. So we never got around to doing the other versions and figured someone else might. Early in the summer of 2000, when I was still at aD, I twisted Jin's arm into leading a small team to do a 100% Java version. And that opened up all kinds of possibilities for new and different execution environments (Tomcat, built-into-Oracle, etc., etc.).

But guess what? Nobody cares. You might think C sucks but you still run your spreadsheet. When I give talks to people in big organizations they often are most impressed by WimpyPoint (see http://www.arsdigita.com/wp/). They've never seen anything like it before and think it is amazing that you can view, at a glance, the most recent work of a whole bunch of people in one orgazation. Having seen it, they ask how to get it. But nobody has ever asked what computer languages were used to build it.

No atomic operations? That does not agree with my experience: if I do a "cvs commit" on a directory, all the files go in at once or they don't go in at all.

One day I add a superfoo() function to foo.c and foo.h, making revision 1.37 of foo.c and 1.22 of foo.h.

Three months later, I am looking at foo.h, which is up to 1.57, and I want to find out everything about the changes that introduced superfoo(). With CVS, as far as I can tell, I look at foo.h's log, see the checkin comment that added superfoo(), hope that the same comment might appear in foo.c's log, but probably have to correlate the two via the ChangeLog file. It's harder when there's not something simple like "superfoo()" to grep for.

With a system with atomic checkins, I look in foo.h's log for the relevant global change number, and then I ask what effect that change number had on foo.c. No manual searching.

It seems to me that the sole reason why GNU projects labouriously maintain ChangeLog files is to cover for the lack of atomic checkins and reporting functionality in CVS.

http://www.arsdigita.com/bboard/q-and-a-fetch-msg? msg%5fid=000bIw&topic%5fid=1257&topic=aD%20Fans%3a %20Boston%2c%20MA

philg waxes poetic on databases.

it's quite informative (at least read the first chapter): SQL for Web Nerds by Philip Greenspun of Philip and Alex's Guide to Web Publishing fame.

Seriously, go read it. It's an afternoon well spent, in that hopefully after reading it you'll understand why comparing MySQL to Oracle is comedic. You have to understand your tools before you pick which one to use (MySQL is for your MP3 id3 tags, Oracle is for your hospital's data storage or for your credit card company's data storage.)

it's quite informative (at least read the first chapter): SQL for Web Nerds by Philip Greenspun of Philip and Alex's Guide to Web Publishing fame.

Seriously, go read it. It's an afternoon well spent, in that hopefully after reading it you'll understand why comparing MySQL to Oracle is comedic. You have to understand your tools before you pick which one to use (MySQL is for your MP3 id3 tags, Oracle is for your hospital's data storage or for your credit card company's data storage.)

For those readers without much database experience, Philip Greenspun has written a readable introduction to databases and RDBMSes.

You should. see this missive from Phil Greenspun. Scan down to the section that says "I want to know the age, sex and zip code..."

Sounds great -- when will we be getting a generic SQL interface?

Unfortunately, the time required to abstract out the DB is significant enough that it's better to just pick a DB and go from there. Arsdigita made this decision and went with Oracle. Slashdot made this decision and went with MySQL.

Although there is a SQL "standard", not many DB vendors adhere 100% to the standard (Oracle being the #1 culprit), or only implement 70% of the standard. You can only do so much with SELECT and UPDATE queries -- eventually you really need something like PL/SQL triggers.

Plus (just to rain on your parade a little more), which DB you choose makes a difference. Go with MySQL? Well, now you have to work around the table-locking problem (a HUGE problem if you're dealing with 100s of users). Go with Informix? You've got a different CHAR limit than Oracle.

Abstraction is a neat idea, but unrealistic. By the time you've worked around the abstraction problem, Outlook is on version 1000 and runs circles around your Free implementation.

The developers where I work need a bug tracking system (right now it's a very crude process, stone tablets, lots of grunting, etc...you get the idea.) We've been considering using the Ticket module from Ars Digita. From the description it does all sorts of nifty things related to bug/enhancement/etc tracking. Anyone have any comments about this particular system?

The developers where I work need a bug tracking system (right now it's a very crude process, stone tablets, lots of grunting, etc...you get the idea.) We've been considering using the Ticket module from Ars Digita. From the description it does all sorts of nifty things related to bug/enhancement/etc tracking. Anyone have any comments about this particular system?

ArsDigita has a great article on using Oracle as a backend for your mail and ACS as a front end.

OpenACS (Open ArsDigita Community System) is an advanced toolkit for building scalable, community-oriented web applications.

and yes, profitable communities online. Heh - you mean like slashdot did?

Anyway - I haven't read this book, but I recommend any readers interested in the subject to check out Phil Greenspun's Online Book - he prefers some pretty whacky languages, servers, and databases - but he gets many ideas accross very clearly regardless.

Sure, you could read this book...

OR, you could read Philip and Alex's Guide to Web Publishing, and learn everything there is know about creating dynamic web sites, for free. That's right; click on the book, and you'll be face to face with one of the best books (and websites) that I have ever read, period.

I've bought the book 3 times in print, because it has the highest circulation amongst my book collection.

Check out Arsdigita and read Phillips notes on e-commerce in "the book". You can use the ACS to take care of this stuff, when it's credit card based.

User is extremely bored and wishes to stare at a blank screen for several minutes while a flashing icon loads, then stare at the flashing icon for a few more minutes.

The phones are light and small, and have sufficient standby time
For example, (my phone the D209i, weighs 74 g, has a 256 color display, roughly 100x100 pixels, and operates 400 hours (standby receive time) between charging. It will sustain about 120 minutes of talk time on a charge.

Put another way, it weighs as much as a pocket full of loose change, and needs to be recharged a couple of times a month with average use.

Remember, the Japanese usually walk and take the train to work, so they *cannot* lug heavy junk around with them. For example, the average 7 lb US laptop that you can throw in the trunk of your car is like hauling a boat anchor around if you are standing on a crowded train for 90 minutes.

People have time on their hands
Most people take the train to work, so they have plenty of time on their hands where they can play with their phone. The same time spent in a car commuting is dead-time as far as Internet usage goes, because you cannot surf the net and drive at the same time.

The phone company has made Internet access from home obscenely expensive
NTT has, even to this day, charged per minute for dialup even for local calls. So for most users the clock is always on if they are dialed into the net from home. By comparison, cell phone rates and packet costs are quite reasonable in comparison.

Point of reference: it costs more for me to make a phone call from my house in Tamagawa to Kawasaki (1 km) than it does for me to call Boston (using ATT @phone service from my home). NTT has literally choked the life out of Internet growth here for the last five years.

People are used to paying money for crap that they would never pay for in the US
CNN charges 300 yen a month to let you read CNN online on your i-mode phone. US users would laugh at the concept of paying to read CNN on a tiny screen. But in Japan, consumers are less accustomed to telling the producers what they want and what they will pay (see previous point about NTT phone rates).

Billing is more fair
The recipient of a phone cell phone call does not pay airtime charges.

More web sites, easier to build them
cHTML (compact HTML) used for i-Mode is easier to write than WAP. It's just basically a subset of HTML 2.0. So developers don't have to make a big investment in new tools or time to make a useful i-Mode site quickly from existing web technology.

Email is still the killer app
Most people make use of the email feature on their phone to one degree or another. Teenagers are legendary for rapid high volume communication, essentially using it for chat applications.

Many people do not have regular internet access from work or home
For various historic reasons (NTT high prices, keyboard problems, incompatible PCs, lack of space in small apartments, lack of access from workplace) PC's are not so common as they are in the US. Thus, using the i-Mode phone for some internet access tasks is a reasonable alternative to buying a PC. This makes a positive feedback loop to encourage more services accessible via i-Mode.

Dunno if these have exactly what you're looking for, but you might try:

• philg's introduction to version control for Web development
• ron's Version Control for Web Development using CVS

Always interesting articles on ASJ.

Hope this helps.

Dunno if these have exactly what you're looking for, but you might try:

• philg's introduction to version control for Web development
• ron's Version Control for Web Development using CVS

Always interesting articles on ASJ.

Hope this helps.

Prof. James Freeman at Cornell College in Mount Vernon Iowa put the Iowa state code online. He argues, convincingly in my opinion, that it's important to provide information as plain old HTML files whenever possible, and minimize dynamic page creation.

For general good advice on Web publishing, I like Philip and Alex's Guide to Web Publishing .

Mike O'Donnell

A key point is to make the office environment more attractive than the home office. I was recently interviewed by a start-up ISP to head up their web development department. The floor was concrete, what walls existed were unfinished drywall, and the desks looked like rejects from the local Salvation Army. Needless to say I didn't take the job.

I think, therefore, ken_i_m

http://www.arsdigita.com

They want to do something that will impress their classmates from MIT or UCLA or Caltech or wherever.

MIT and Caltech must be really overrated if all it takes to impress the students who graduate from there is a job doing web scripting and 3 tier applications that any high schooler can do with PHP, ASP or Perl.
Then again, maybe you guys simply hired the bottom of the barrel.

If they get sick of it they can always join a slacker company and work 40 hours/week.

Such as i2, Trilogy, Cisco or Microsoft, huh?
<sarcasm> Of course, your hotshit web development shop makes these companies look like mom-N-pop shops. <sarcasm>

The more I read about Ars Digita, the less impressed I am. From the trivial bootcamps and gross overpayment for monkey work (web scripting, pah) to the fact that some of you think using fuck in code is a mark of professionalism, I had mentally filed Ars Digita as yet another hotshit startup that won't last the next half decade.

From the descriptions I've gotten of ArsDigita both from employees and boot camp attendees, the place is a hackers playground where and software engineering and computer science practices are paid lip service. Particularly amusing is the fact that you guys think that your online degree program which is merely a glorified course in Web Development is equivalent to a degree from MIT
*LOL*

Second Law of Blissful Ignorance

by Philip Greenspun (philg@mit.edu)

Submitted on: 2000-10-22

ArsDigita : ArsDigita Systems Journal : 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.

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. Morever, 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. A programmer probably needs to spend 25 hours per week getting coordinated with other programmers and comprehending the structures of the systems being extended. Thus a programmer who works 55 hours per week is twice as productive 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:

1. 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.
2. 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.
3. 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.
• 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.

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 1, 2000

Not to mention that 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 2, 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 2, 2000

by Philip Greenspun (philg@mit.edu)

Submitted on: 2000-10-22

ArsDigita : ArsDigita Systems Journal : 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.

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. Morever, 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. A programmer probably needs to spend 25 hours per week getting coordinated with other programmers and comprehending the structures of the systems being extended. Thus a programmer who works 55 hours per week is twice as productive 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:

1. 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.
2. 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.
3. 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.
• 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.

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 1, 2000

Not to mention that 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 2, 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 2, 2000

by Philip Greenspun (philg@mit.edu)

Submitted on: 2000-10-22

ArsDigita : ArsDigita Systems Journal : 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.

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. Morever, 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. A programmer probably needs to spend 25 hours per week getting coordinated with other programmers and comprehending the structures of the systems being extended. Thus a programmer who works 55 hours per week is twice as productive 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:

1. 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.
2. 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.
3. 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.
• 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.

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 1, 2000

Not to mention that 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 2, 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 2, 2000

Philip Greenspun's book (reviewed/interviewed on /.), Philip and Alex's Guide to Web Publishing (full text free online) has some interesting coverage of this stuff, too.

Philip Greenspun's book (reviewed/interviewed on /.), Philip and Alex's Guide to Web Publishing (full text free online) has some interesting coverage of this stuff, too.

Not to name names too much, but at Ars Digita, which until recently had a fairly aggressive recruitment policy, there are no openings for development engineers at the moment. Granted, they are in web development, but a shortage of openings there and at related companies must be having some kind of effect on the job market overall...

just my 0.02...

I've been playing with AOLServer recently and would like to know how much of a performance advantage it currently has over Apache. (Used to be 10 times faster than Apache)

For those who don't know, AOLServer, formerly NaviServer, was built in 1994 by Jim Davidson and Doug McKee. It was then bought by AOL and GPLed a little later. More info here.

Regret for the past, Is a waste of spirit.

... replace older working American programmers with cheaper H1-B Visa programmers ...

Yes, it is happening ... the shop I work for is now evaluating proposals from several bodyshops - some offshore, some on-shore but still comprised mostly of H1-B imported foreign programmers ... the employees are urged to seek "management" path careers as the trend is to farm out the coding (both support and development to "bodyshops") ... and this has already occurred for many of the departments of the very large company I work for ... it is getting hard to communicate in English - for a global firm that predominately does mostly U.S. business ...

How is it these clowns (the US House/Senate think they are doing high-tech industry good by this action? They are pandering to the lords of industry ... it sucks ... I will find work - even now, my management is urging the bodyshop to retain some of the "professionals" who know the system well to enable a smooth transition and ensure the same quality support ...

Make no mistake about it - this is not about a shortage of programmers - it is 100%, absolutely about cheap labor ... and the management in my company makes no bones about it - as their #1 goal is to reduce costs 10% per year in providing systems support/development for the business units ...

I am so angry ... I have nothing against the talented professionals that wish to perform their craft ... but call a spade a spade ... this charade is infuriating ... I wish there was something I could do - I am only one voice, but as it happens to others, they will feel the same way though most of the country probally could give a rat's ass ...

These people (US House/Senate, lords of industry, etc ...) are taking the bread out of my children's mouth ... I urge all to read Debunking the Myth of a Desperate Labor Shortage

And I'll sign off with some words from Phillip Greenspun in his famous book on web publishing ...

My personal theory requires a little bit of history. Grizzled old hackers tell of going into insurance companies in the 1960s. The typical computer cost at least $500,000 and held data of great value. When Cromwell & Jeeves Insurance needed custom software, they didn't say, "Maybe we can save a few centimes by hiring a team of guys in India." They hired the best programmers they could find from MIT and didn't balk at paying $10,000 for a week of hard work. Back in those days, $10,000 was enough to hire a manager for a whole year, a fact not lost on managers who found it increasingly irksome.

Managers control companies, and hence policies that irk managers tend to be curtailed. Nowadays, companies have large programming staffs earning, in real dollars, one-third of what good programmers earned in the 1960s. When even that seems excessive, work is contracted out to code factories in India. Balance has been restored. Managers are once again earning three to ten times what their technical staff earn. The only problem with this arrangement is that most of today's working programmers don't know how to program. Companies turn over projects to their horde of cubicle-dwelling C-programming drones and then are surprised when, two years later, they find only a tangled useless mess of bugs and a bill for $3 million. This does not lead companies to reflect on the fact that all the smart people in their college class went to medical, law, or business school. Instead, they embark on a quest for tools that will make programming simpler. Consider the case of Judy CIO who is flying off to meet with the executives at Junkware Systems. Judy will book her airplane ticket using a reliable reservation system programmed by highly-paid wizards in the 1960s. There is no middleware in an airline reservation system. There is no Microsoft software. There is no code written by C drones. Just one big IBM mainframe.

Judy changes planes in the new Denver airport. She could reflect on the fact that the airport opened a couple of years late because the horde of C programmers couldn't make the computerized baggage handling system work (it was eventually scrapped). She could reflect on the fact that the air traffic controllers up in the tower are still using software from the 1960s because the FAA can't get their new pile of C code to work--billions of dollars, 15 years, and acres of cubicles stuffed with $50,000-per-year programmers wasn't good for much besides a lot of memory allocation bugs. She could compare the high programmer salaries of the past and their still-working software to the low programmer salaries of the present and their comprehensive collection of bloated bug-ridden ready-any-year-now systems. However, these kinds of reflections aren't very productive for a forward-looking CIO. Judy uses her time at the airport to catch up on what passes for literature among MBAs: The Road Ahead and Dollar Signs : An Astrological Guide to Personal Finance.

I'm terribly enthusiastic about OpenSource Educational Material.

Open Publications can provide us with much more than merely free and improved literature. We can apply groupware concepts to online education and build a very modular and exacting approach to education. Knowledge requirements for particular subjects can be made explicit and linked to. Community systems (such as ArsDigita's) can be applied in order to permit annotation, both textual and graphical, chat rooms (the largest study group in history), and other assistants to understanding material. Multiple explanations of the same subject can be given side-by-side. Methods of explaining can be analyzed and optimized.

OpenContent books such as Havoc's book Gnome/GTK+ Application Developmentappear to be doing well on the shelves. I haven't witnessed price wars yet; most Open Publication books are only being published by one publisher, even though there is nothing to preventing republishing. Indeed, it makes me wonder why more books are not published under free licenses.

Publishers' roles (and living) will not disappear until book compilers are commonplace, even though content may be liberated; I, and several others, severally annotate our books. (My copy of House Of Leaves has a lot more in blue than just the word "House".)

I've always been partial to Philip Greenspun's philosophy of Web design. It's a classic.

Now hiring experienced client- & server-side developers

While Imedix is a cool product, I don't think it will meet his needs for a general purpose EMR.

The ACS (or OpenACS) can be customized to suit a variety of tasks, but no EMR module yet exists. So be prepared to do a little bit of hacking/data model extension. Drop me mail if you are interested in taking this route.

A better bet for what you're trying to do (at this point) is probably GNUmed. It uses Postgresql for its database layer (passes the ACID test). Dr. Horst Herb and his crew have built the software in a very thoughtful fashion -- they've clearly used lots of commercial products before.

One final thing to remember for those who wish to go it alone & code their own product is the importance of security.

Good security is critical for all EMR software, but is of particular concern in the USA, where HIPAA rules are starting to be implemented.

Because of these rules, the task of developing an EMR for use as a permanent medical record has become more time consuming, and complex. The law is, ultimately, a consumer protection act, and should lead to higher-quality, standards-driven EMRs in the future. Be sure to examine the rules before setting out on any healthcare project.

hope it helps.

Try Imedix.com / ArsDigita? Their basic toolkit, ArsDigita Community System, is gpl'ed, suspect you have to pay for the medical stuff though, plus of course any customization needed if you let them do it.

Try Imedix.com / ArsDigita? Their basic toolkit, ArsDigita Community System, is gpl'ed, suspect you have to pay for the medical stuff though, plus of course any customization needed if you let them do it.

Read this.

And $Oz2500 PER CPU for an "Internet Connector" licence if we want our SQL database to be web-enabled.

If you think that's absurd, look at what Philip Greenspun has to say about RDBMS pricing. M$ $QL $erver is actually one of your cheapest options, and one of only two commercial RDBMSes that actually publishes prices. (SOLID is the other one.) M$ $QL $erver, for what it is, actually isn't that bad (they stole most of it from Sybase), although it bites big for most web stuff because it supports a laughable 256 character VARCHAR and because all of the JDBC drivers are closed-source and expensive (you can use the ODBC-JDBC bridge, but it's slow).

Of course, I'd recommend PostgreSQL if you don't want to pay for a database, or MySQL if you don't want to pay for a filesystem. :-)


~wog

From what i know about ServerBench it uses a threaded IO model on NT, but a fork/process model on Linux.

Instead of getting all wrapped around benchmarks (let alone closed-source benchmarks!) we would be better off paying attention to the efficiency of the server program:

Speed

It is so easy now to get a high-efficiency server program that speed is no longer a significant discriminant. In ancient times, the Web server forked a new process every time a user requested a page, graphic, or other file. The second generation of Web servers pre-forked a big pool of processes, e.g., 64 of them, and let each one handle a user. The server computer's operating system ensured that each process got a fair share of the computer's resources. A computer running a pre-forking server could handle at least three times the load. The latest generation of Web server programs uses a single process with internal threads. This has resulted in another tripling of performance.

It is possible to throw away 90 percent of your computer's resources by choosing the wrong Web server program. Traffic is so low at most sites and computer hardware so cheap that this doesn't become a problem until the big day when the site gets listed on the Netscape site's What's New page. In the summer of 1996, that link delivered several extra users every second at the Bill Gates Personal Wealth Clock ( http://www.webho.com/WealthClock). Every other site on Netscape's list was unreachable. The Wealth Clock was working perfectly from a slice of a 70 Mhz pizza-box computer...

From what i know about ServerBench it uses a threaded IO model on NT, but a fork/process model on Linux.

Instead of getting all wrapped around benchmarks (let alone closed-source benchmarks!) we would be better off paying attention to the efficiency of the server program:

Speed

It is so easy now to get a high-efficiency server program that speed is no longer a significant discriminant. In ancient times, the Web server forked a new process every time a user requested a page, graphic, or other file. The second generation of Web servers pre-forked a big pool of processes, e.g., 64 of them, and let each one handle a user. The server computer's operating system ensured that each process got a fair share of the computer's resources. A computer running a pre-forking server could handle at least three times the load. The latest generation of Web server programs uses a single process with internal threads. This has resulted in another tripling of performance.

It is possible to throw away 90 percent of your computer's resources by choosing the wrong Web server program. Traffic is so low at most sites and computer hardware so cheap that this doesn't become a problem until the big day when the site gets listed on the Netscape site's What's New page. In the summer of 1996, that link delivered several extra users every second at the Bill Gates Personal Wealth Clock ( http://www.webho.com/WealthClock). Every other site on Netscape's list was unreachable. The Wealth Clock was working perfectly from a slice of a 70 Mhz pizza-box computer...