HW12: Mythical Man Month
Once again we have Brooks here this time with shorter essays on the pitfalls and virtues of programming. I really do enjoy reading him because of the immense experience and his work managing the OS/360 development which he says at one point had over 1,000 people (and that’s in the 60’s)! The essays in this collection all have to do with why it’s so hard to program. And as a programmer with over ten years of experience I can certainly attest to the claims.
The tar pit is the first essay where almost poetically Brooks explains that programming is like two giant beasts struggling in a tar pit the more movement the stickier everything gets. I think that’s a common occurrence in big programming projects to just try and through everything but the kitchen sink (or is it everything and the kitchen sink) towards a project that is having delays. And what we usually see happen is that the delays continue. Brook’s Law: Adding manpower to a late software project makes it later.
There is good explanations as to why programming can be so fun. I say can be because oftentimes I’ve found that you start off as a junior programmer not really doing fun things but just working on other people’s mess. If you’re lucky you find a job where you are afforded a lot of time to be creative and design your own solutions to problems. I agree with many of the reasons cited like the joy of learning and the joy of seeing that was born in your mind be useful to someone. And isn’t that the point, to add value wherever possible?
The essay about modelling programming teams like surgical teams was pretty interesting. I thought the analogy could have been explained a little better as to maybe why is it that surgical teams are divided that way they are but overall very interesting. I think nowadays we don’t need as many clerks AS LONG as we are following the best practices and committing with clear descriptions and reviewing code and doing good QA. I think it was excellent to point out that the person that should really be documenting a lot of the mechanisms of the code should be the chief programmer, as much as a lot of hackers hate to hear that — why go through all the painstaking trouble of creating something so complex that only you understand it and even then, when you have to come back to it years later how will you ever understand it without good documentation. At least these days there’s more ways to safeguard against this type of programming if we use TDD, for instance.
In the last essay we deal with the question of Aristocracy here mostly understood as the architects or democracy here being understood as the users or implementers. In terms of designing a good system how much sway should one group have over the other? I’ve personally not heard or been part of many of the struggles I’m sure have occurred over the years but I agree that for conceptual integrity we need architects and not many of them to think alike to solve common issues. However the other argument is that people actually designing the implementions using the external specification designed by the architects aren’t doing lesser creative work. Here an example of Bach having to produce a weekly cantata is proof positive that his creativity wasn’t stymied.