The genesis of this work was my feeling that these companies were working very hard and producing poor software, missing schedules and not understanding why.

Following are some trends and my thoughts about them. I should mention that my thinking has been very much influenced by C. A. R. Hoare's Turing Award lecture and The Mythical Man Month. I hope to add to this list of influences as time goes on.

This tends to rule out things like documentation, design meetings, software quality. I suspect it is a reaction to the myth of the bloated giant (IBM) and stories of their development processes.

My experience with programming is that it requires a lot of thought to do well and is mentally taxing. I believe that I write better code when I am fresh than when I'm fatigued. The question is how many hours can one work before the quality of code produced drops below the point where it is more efficient to stop coding and rest than keep coding.

Obviously this varies according to how challenging the task is. For a back of the envelope calculation, assume that a programmer can write code for 6 hours before becoming noticably fatigued. If the programmer is coding an average of 12 hours/day, then 1/2 of his code is written when fatigued. If this is the norm then 1/2 of the code in the product is substandard.

Code is seen as a black box, only the programmer who wrote it ever looks inside, everyone else can only look at the external behavior

It is a bad sign when programmers are reluctant to show others their code or seem embarassed by what they have written.

If the programmer who wrote the code doesn't think it is very good, then it probably isn't.

How is it determined whether a programmer is writing quality code? How are the expectations and quality standards communicated and verified?

Programmers are treated as peers and the organization is described in egalitarian terms, so there is nobody in charge of software quality.

Programmers who are peers can be in charge of different parts of the system but nobody has review authority over another programmer. This works with the black box problem to keep inferior quality software from being discovered and allows it to become part of the product.

It is a common problem that good programmers tend to get opportunities and leave teams, while poor programmers are less likely to and so more likely to stay. If there is no internal mechanism for identifying and removing poor programmers, then the steady state team will be dominated by them.

Effort and commitment are necessary and sufficient behaviors for good programmers to produce a product

I once had a coworker tell me that if we all worked hard and were committed in our hearts we would surely succeed. I think this kind of thing arises when there is no way to measure or understand the development process. Such a programmer has a strong emotional yearning for success without any concrete means for bringing the success about.

It shouldn't be suprising that software development could be viewed like magic, where it is required that one be pure of heart and strong of will to succeed, or like the cancer treatments that require you to believe in your body's ability to vanquish the cancer. It's one virtue is that it makes it easy assign blame when the project fails (someone didn't have a genuine commitment).

There is no mechanism for measuring and adjusting the development process once it starts. If the software team is not advancing towards delivering the correct system on time, it won't be discovered until 3 weeks before the deadline.

This is basically out of The Mythical Man Month and is a consequence of some of the above properties. Since everyone is committed and working as hard as possible it is assumed that they will succeed as soon as it is possible to succeed. Whether the programmers are on track or are have diverted is unknown and won't be discovered until integration time since there is no review process.

Brooks describes a kind of development where the project is written top down, all of the modules initially stubbed out or implemented with dummy functions. The project grows down as time passes, dummy functions are replaced with real code. This kind of project is always in a working state since the dummy functions all work. This may help keep the programmers on track, since they will know from the beginning whether their work integrates.