| I second the recommendation for MM-M, after recently reading it. You may find the chapters around how to structure a team to be interesting. Here's my review (posted elsewhere): ---- I decided to give MM-M a read, after seeing it repeatedly listed as one of the classics of the fledgling - as the book maintains - field of software “engineering”. Despite a few dry chapters extensively detailing the development of OS/360, the book holds up remarkably well for being forty years old. Indeed, many of its central, oft-repeated development aphorisms still hold value. Unfortunately, its advocacy for extensive and exhaustive planning and documentation cycles screams “waterfall”, and muddies what is otherwise - I think - a number of worthwhile recommendations: 1. Avoid the second-system effect by being ruthlessly practical 2. Build a prototype and throw it away 3. The essence of programming has an irreducible complexity Aside from these, I noted with great interest Brooks’ suggested team structure which he refers to as a surgical team: 6-7 people in highly stratified, and complimentary roles, led principally by a “surgeon”-type chief architect. I’ve only worked within relatively flat team structures up to this point, typically set up in junior/senior relationships. Since this is a less frequently cited recommendation in the book, I’m curious to know if it has been implemented with any success. Finally, this suggestion is tantilizing: As a discipline, we need an extended information theory that quantifies the information content of static structures, just as Shannon’s theory does for communicated streams. |