Chapter 1
I think the difficulty for any artist or professional is finding a way to do what you love in a way that makes you money. I love music, but I don’t love it enough to fight through the grinding business aspects of actually being a musician. I love coding, but I don’t love debugging, and Brooks reminds me that this is true for the vast majority of programmers. People have to plug what they love doing into a system that includes all kinds of extra crap that most people don’t want to have to deal with. I have biologist friends who got into the field because they love the scientific process and love living systems. Then they have to write grant application after grant application, or suspend their work while the government decides whether it’s going to continue funding that work this fiscal year, and they occasionally forget why they started doing this thing in the first place. I guess the answer is to find a way to be a professional that still let’s you be successful and have some fun doing it.
Chapter 2
The ubiquitous misconception that effort = productivity really hit home for me, because I experience it as a student and see it as a teacher. Sort of the classic American dream is that if you put in your hours you’ll be rewarded. This paradigm is challenged, to the frustration of normal people, when someone gets rich quick with some brilliant or at least marketable new idea, from propane lanterns to Angry Birds. It seems clear that at least some of the time a burst of brilliance gets you much further than working long hours with little sleep and consequently worn out creativity. As a student I’ve gotten better at understanding when I will be productive and getting the right amount of food, sleep, and caffeine to be ready to get a lot of good work produced during those times. Few professional tasks, unless you’re an accountant, require a constant amount of time to complete. As a teacher, I have the frustrating experience of seeing students who work tirelessly (and very tiredly) earn worse grades than students who seem bright-eyed and well-rested after spending a quarter of the time the first student did to study or complete an assignment. It’s hard to learn to work and study smarter, but this concept applies to nearly every professional and certainly applies to software development.
With any project, especially one where the doing is all the fun, taking the time to plan requires lots of discipline. Of course planning is of the utmost importance in any engineering project, but the natural gravity of the situation that would be apparent if trying to haphazardly assemble a bridge or a spaceship isn’t visible for software developers. There’s nothing like standing on a wobbly half-finished bridge or watching video of a spacecraft disaster to remind you that a screw up is a big deal. I just don’t know that the idea of software screw ups can be as visceral. Even if a programmer is keenly aware of the seriousness of the system, it’s just hard to visualize the system and consider all of the moving parts. And, even the very serious and thorough programmer sometimes just wants to say screw it, grab a Mtn. Dew (lots of them), and start coding. I like the rule of thumb that Brooks presents that shows just how much of a successful project is spent planning and testing and how little is spent coding.
Chapters 3-4
The surgical team idea sounds pragmatic, but I don’t know how many programmers want to learn programming in order to become the one who hands the surgeon the scalpel. I don’t know that conceptual integrity requires that only one particular person is the only one with hands on the program design. If we want to continue with the surgical team analogy, there are complex surgeries that will require multiple surgeons with different specialties to work on different parts of the system. No one surgeon knows how to do everything. In fact, as surgeons get more experienced they tend to become more and more specialized at one small set of things. I think a football team might be a more palatable analogy and has the advantage of passing the ball around to whoever has the particular skill that is needed at that time. The QB has the responsibility of keeping the team focused and synchronized, but he doesn’t have to always be the one holding the surgical tools.
Regarding the architecture analogy, when we say that this one architect designed a fabulous building, it’s not true to say that that one architect was the surgeon. That chief architect developed the high-level framework but also managed a large team of subordinate architects that all worked on small pieces of the puzzle. I don’t know that these small pieces of the puzzle necessarily required their own surgical team either. I think there are cases where one of these component architects can design something that is great and that then gets passed through review processes that are ultimately held together with conceptual integrity by the chief architect.
I think the only difference between my takes on the surgical analogy and architectural analogy and those of the author is probably just a matter of how finely to slice up the whole project. Brooks describes at a very high level the need to have surgical teams tackle individual pieces of the project, and I am probably just having a hard time figuring out how many of these pieces there are in any given project. Perhaps each football player in my football analogy has his own surgical team helping him accomplish his own particular specialty. If that’s the case, then it sounds great to me! I still hate football, but hey.