The craft of programming "gratifies creative longings built deep within us and delights sensibilities we have in common with all men," providing five kinds of joys:

• The joy of making things
• The joy of making things that are useful to other people
• The fascination of fashioning puzzle-like objects of interlocking moving parts
• The joy of always learning, of a nonrepeating task
• The delight of working in a medium so tractable – pure thought-stuff – which nevertheless exists, moves, and works in a way that word-objects do not.

Likewise the craft has special woes inherent in it:

• Adjusting to the requirement of perfection is the hardest part of learning to program
• Others set one’s objectives and one must depend upon things (especially programs) one cannot control; the authority is not equal to the responsibility
• This sounds worse than it is: actual authority comes from momentum of accomplishment
• With any creativity come dreary hours of painstaking labour; programming is no exception
• The programming project converges more slowly the nearer one gets to the end, whereas one expects it to converge faster as one approaches to the end.
• One’s product is always threatened with obsolescence before completion. The real tiger is never a match for the paper one, unless real use is wanted

All programmers are optimists: "All will go well"

My comment: I suppose there are two tasks, which programmers do not like at all. The first is the documentation, the second is testing. A programmer should not perform testing by himself because I think that he develops a certain "mother-child" relationship to his product. As Russian Jews used to say in the 19^th century, "it is more likely that the Czar will change his religion to Judaism than a mother will admit that her son or daughter is less talented than Albert Einstein or Marie Curie". That partially applies also to programmers and their programs. One doesn’t want to hurt his baby, in particular if the creation of that baby involved a lot of thinking and creative work.

On the other side, the value system of programmer and tester is different. A programmer may consider some (from user’s point of view) cryptic text in a dialog box a trifle compared with a complex representation of a business process which does work correctly and (computationally) efficiently.

I also made the experience, that I evaluate programs differently if they are programmed by myself or by another person. I think one detects other person’s errors and failures more quickly than one’s own (thus the sense of pair programming in XP).

Because the programmer builds with pure thought-stuff, we expect few difficulties in implementation.

My comment: We don’t, and make errors nevertheless.

But our ideas themselves are faulty, so we have bugs.

Partitioning a task among multiple people occasions extra communications effort – training and intercommunication.

Brooks’s Law: Adding manpower to a late software project makes it later

Adding people to a software project increases the total effort necessary in three ways: the work and disruption of repartitioning itself, training the new people and added intercommunication

Very good professional programmers are ten times as productive as poor ones, at same training and two-year experience level.

Sackman, Grant, and Erickson’s data showed no correlation whatsoever between experience and performance.

A small sharp team is best – as few minds as possible.

A team of two, with one the leader, is often the best use of minds.

A small sharp team is too slow for really big systems.

Most experiences with really large systems show the brute-force approach to scaling up to be costly, slow, inefficient, and to produce systems that are not conceptually integrated.

A chief programmer, surgical team organisation offers a way to get the product integrity of few minds and the total productivity of many helpers, with radically reduced communication.

To achieve conceptual integrity, a design must proceed from one mind or a small group of agreeing minds.

Separation of architectural effort from implementation is a very powerful way of getting conceptual integration on very large projects"

If a system is to have conceptual integrity, someone must control the concepts. That is an aristocracy that needs no apology.

The Tower of Babel failed because of lack of communication and of its consequent, organisation.

Teams should communicate with one another in as many ways as possible: informally, by regular project meetings with technical briefings and via a shared formal project workbook (and by e-mail).

The purpose of organisation is to reduce the amount of communication and co-ordination necessary.

Organisation embodies division of labour and specialisation of function in order to obviate communication.

The conventional tree organisation reflects the authority structure principle that no person can serve two masters.

The communication structure in an organisation is a network, not a tree, so all kinds of special organisation mechanisms ("dotted lines") have to be devised to overcome the communication deficiencies of the tree-structured organisation.

Every subproject has two leadership roles to be filled, that of the producer and that of the technical director or architect. The functions of the two roles are quite distinct and require different talents.

The project boss must work at keeping the managers and the technical people as interchangeable as their talents allow; in particular, one wants to be able to move people easily between technical and managerial roles.

The barriers to effective dual-ladder organisation are sociological, and they must be fought with constant vigilance and energy.

It is easy to establish corresponding salary scales for the corresponding rungs on a dual ladder, but it requires strong proactive measures to give them corresponding prestige: equal offices, equal support services, over-compensating management actions.

Organising as a surgical team is a radical attack on all aspects of this problem. It is really the long-run answer to the problem of flexible organisation.