Adding manpower to a late software project makes it later. (Brooks Law, p. 25)
The Mythical Man-Month by Frederick P. Brooks Jr. was first published in 1975, but it still reads easily and wisely. At its heart is an understanding of how programming is a human task which takes communication to do in teams. As Brooks puts it, “Men and months are interchangeable commodities only when a task can partitioned among many workers with no communication among them.” (p. 16) For this reason you can’t just throw more people at a project to get it finished faster. Some other quotes:
The bearing of a child takes nine months, no mater how many women are assigned. Many software tasks have this characteristic because of the sequential nature of debugging. (p. 17)
Even at this late date, many programming projects are still operated like machine shops so far as tools are concerned. Each master mechanic has his own personal set, collected over a lifetime and carefully locked and guarded – the visible evidence of personal skills. Just so, the programmer keeps little editors, sorts, binary dumps, disk space utilities, etc., stashed away in his file.
Such an approach, however, is foolish for the programming project. (p. 128)
A computer program is a message from a man to a machine. The rigidly marshaled syntax and the scrupulous definitions all exist to make intention clear to the dumb engine.
But a written program has another face, that which tells its story to the human user. (p. 164)
building software will always be hard. There is inherently no silver bullet. (p. 182)
The complexity of software is an essential property, not an accidental one. Hence descriptions of a software entity that abstract away its complexity often abstract away its essence. (p. 183)
In the chapter “The Surgical Team” he proposes that programming be done in a small team like a surgical team around an experienced programmer. The team would have a Chief Programmer, Copilot, Administrator, Editor, Secretaries, Program Clerk, Toolsmith, Tester and Language Lawyer. The Editor would help document code. The Copilot would work closely with the programmer discussing design with her – which sounds like extreme programming. The Toolsmith makes sure the computers are running right. The Language Lawyer would be the resource for the programming language.
Still the wisest book I’ve ever read about managing software development projects. Second on my list would be The Pragmatic Programmer by Andy Hunt and Dave Thomas, which is more focused on the individual programmer, but is similarly suffused with earthy advice and good sense about everything from object-oriented design to commenting code.