[paddy_m]

I am surprised that there's less mention of Brook's proposed team organization, a team of 10 led by a surgeon. The team is supposed to work on a single project. Every org I have seen has much smaller teams with much more individual responsibility and attendant coordination problems.

I can see shaving 1-3 people off of Brook's ideal team (we don't need a secretary to type anymore, PM's that organize projects at the behest of a technical leader are effective).

What I have seen over and over is, whoever writes the most code tends to get the most power in an org. Whoever is delivering features quickly gets power. This kind of works, but these coders frequently leave poorly thought out architecture that is hard to extend.

[dmbche]

Classic "You get promoted until you are incompetent" situation

[loloquwowndueo]

That’s another book: the Peter Principle, by Laurence J. Peter. It’s also in my “books you need to read if you’re going to work on a development team” list.

[sebg]

Intrigued to hear what else is on your list?

[loloquwowndueo]

My go-tos are the mythical man month and Peopleware:productive projects and teams. There’s the Peter principle too. On more technical (slightly) topics, I like the Pragmatic Programmer. I also like people to be aware of re-engineering concepts, so Hammer and Champy’s Re-engineering the Corporation is also good.

[dredmorbius]

A good set.

Arthur Bloch's Murphy's Law and Other Reasons Why Things go ƃuoɹʍ is a compendium of engineering and organisational dictums. Of itself it provides relatively little insight, but many of the principles themselves trace to more substantive works, including Parkinson's Laws, the Peter Principle, and many, many others:

<https://archive.org/details/murphyslawotherr0000bloc>

Bloch himself was working off a number of earlier compilations, several already popular in the high-tech industry (programming, weapons design, biotech, etc.), as well as other fields. I'd tracked those down at one point but seem to have lost those references. Bloch cites some, though not all, his sources in this and subsequent "Murphy's Law" books.

"Gamesmanship" and "Systemantics" cover similar ground:

<https://en.m.wikipedia.org/wiki/Gamesmanship>

<https://en.m.wikipedia.org/wiki/Systemantics>

See also Richard I. Cook's "How Complex Systems Fail": <http://web.mit.edu/2.75/resources/random/How%20Complex%20Sys...>

Charles Perrow explores organisational foundations of failure in Normal Accidents and The Next Catastrophe. To an extent Joseph Tainter and Jerard Diamond's books (particular each author's independent Collapse titles) look into the dynamic at much greater depth.

For programming, MMM (Brooks), PeopleWare (Demarco & Lister), The Psychology of Computer Programming (Weinberg), Code Complete (McConnell), and a substantial literature on quality assessment and practices emerged in the 1970s -- 1990s. The bibliographies of the above books, as well as citations of them, should provide an ample set of references for further reading.

[tmcdos]

You should also read the Parkinson's law. It's more about bureaucratic systems but is not any org such a system?

[loloquwowndueo]

Thanks for the reco!

[layer8]

Not only that, but there is a threshold where delivering features more quickly may indicate poorly thought-out, hard-to-maintain code. So you really need to have an experienced developer as a supervisor to assess quality of implementation, and not just look at the quantity of features delivered.