Microsoft Internet Explorer is a much better browser than Netscape Navigator and yet it was written by a much smaller team: only about 30 developers.

I'm surprised to hear this from Greenspun...

-- Anson Ann, November 6, 2000

The article is great, save one persistent misconception -- it is not necessary to work so many hours to be a great programmer. Yes, at times, the great programmers go larval and spend lot's of time hacking code. But the author's comment about seeing your programmers going home at 6pm and making the judgement that they should be challenged to stay longer is quite destructive.

I have worked the 70 hour weeks, it was fun, and we did great things. But there was also some great loss (to friends and family) induced by those long hours. I find it disturbing that the article basically encourages managers to find people whom can be coerced (incented, challenged, pick your euphemism) into working such long hours at the expense of all else.

There are some truly great programmers here where I work who wouldn't be here if management followed that advice.

-- Ron Forrester, November 6, 2000

While I generally agree with most of the material presented in this article, I have to take issue that there is some linkage between working long hours and productivity. As a software engineering manager, I generally found that I had to send people home to keep them productive. After 8 or 9 hours, regardless of skill level programmers lose their edge and cannot concentrate. In some severe cases, really good engineers can burn out. I had one developer working for me who wanted to work a twelve hour day ($$$). I vetoed the idea, my management overruled me, and three months later the engineer, whom I very highly regarded, had a nervous breakdown and was lost to the company.

Another thing that must be taught, and I did not see this in the article at all, is working hard vs. working smart. Unfortunately, there is a lot of grunt work when developing software products. Tools, whether purchased or built in-house can really help improve both productivity and morale. But software engineers, especially the neophites, may not realize this. I always stressed to my teams that if there were repetitive operations being performed, they should think "tool". A lazy programmer is a productive programmer.

-- Brian Berenbach, November 6, 2000

This is a great article on software engineering with plenty of good examples on the difficulties of managing software engineers. Every manager should read this to gain a proper perspective on managing a project. But, I disagree with this one statement:

"One of the paradoxes of software engineering is that people with bad ideas and low productivity often think of themselves as supremely capable."

How can anyone be so arrogant? Maybe these people are so lost, that this is the only conclusion they can accept? Nah...it's gibberish.

On the other side of the coin, how does software engineer find a circle of good programmers, since determining good/great programmers is already extremely difficult? Being a "leaf-node" myself, I am constantly trying to rate the software landscape and trying to determine the next Ariba or Internet Explorer. Some say it's impossible and I'll never find that opportunity. Is it inevitible to always have bad programmers/members on the project? Are we all doomed to one end or another to manage these "bad idea and low productivity" people?

-- David Peng, November 6, 2000