The Code Crafter's Bible
May. 18th, 2014 02:55 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mtvesselOct 2013
The Mythical Man-Month - Frederick P. Brooks, Jr - Addison Wesley, 1995
* * *
This book is regarded as one of the classic texts about software project management, an activity that is an increasing part of my day job. So I thought I had better read it. Sadly, "classic" it is not. Much of the information and suggested practices in it are hilariously irrelevant to the modern working environment (microfiche for project management documents, anyone?). That said, there are a few classic nuggets to be found, and even the ways in which it has dated tell us something about how the world of work has evolved since it was written. Not least that having women in IT is not just socially desirable, but may directly improve the chances of success of a software project.
Brooks is clearly rather an odd cove. There aren't that many technical books where the preface ends with an invocation to the glory of God. And although it is dedicated to his wife, she is the only feminine reference to be found in the whole thing. One gets the impression that IBM in the 1970s was as all-male as a monastery. Whether this is true, or whether Brooks just has an impatience with gender-neutral grammatical formulations, is not entirely clear. Though it's fair to say that his sexist title has a pithy memorability for which I can't think of a female-friendly alternative (The Paradoxical Person-Period? The Whimsical Woman-Week?).
His main point boils down to a law of diminishing returns in the assignment of human resources to projects. When a software development effort starts to go off-plan, the first instinct of a manager is typically to add extra developers to help get it back on track. But the disruptive effect of an extra member of the team - the additional personal communications needed to make them effective - means that a new developer can end up making the project even later than it would have been before. All projects also have "choke points" - specifically, analysis, design and debugging of specific components - which can only be sensibly be done by one brain at a time. Knowing when not to assign people to a project is as important as knowing when to assign them.
Brooks' solution to effective management is a highly hierarchical team with a "surgeon" (chief programmer) and "co-pilot" (secondary programmer) and a large support team of administrators, secretaries(!), editors, testers, toolsmiths and programming clerks who do everything not directly related to the primary code. For large products he advocates a number of such teams all co-ordinated by a systems architect. He says that consistency of design is key to an application's success and that this can only sensibly be achieved if a single person is responsible for the design.
To a large extent I agree, but the notion of the almighty Systems Architect to whom everyone else must bow down is quite ludicrously patriarchal. Yes, singularity of vision is important, but human frailty means that an architect will often get things wrong or will fail to articulate their design adequately to the other members of the team. The best human systems are more collegiate - they have checks and balances so that mistakes by individuals can be spotted and corrected by colleagues. This works better for everyone. Leaders are not paralysed by fear of doing the wrong thing and followers feel valued and empowered to contribute to the success of the product. Of course groupthink and responsibility-dodging must be avoided, but in my opinion designs by (small) committees are usually better than ones created by an individual working alone.
There is a valuable lesson to be learned from Brooks' analysis, however, and that is the importance of good and efficient communication within a software development team (to this I would add the importance of communicating and empathising with the ultimate users of the software - a subject about which Brooks has curiously little to say). Now I don’t think it is too controversial to say that personal communication is something that women, in general, do better than men. So it follows that having women on a development team is likely to increase its chances of success. Brooks cannot make this point because his vision is blinkered, but it is implicit in his analysis.
Brooks' approach has also been undercut by economic and social developments. In his formulation, a development team would consist of 20% programmers and 80% support staff. The only way to pay for such a team would be to charge a fortune for the product. But that is not the way of the modern world, where price is a key consideration for customers and generous people in the open source movement and the ground-swell of capable programmers from places like eastern Europe and India act to bear down on costs. Brooks want to build a Rolls-Royce, but most of us are happy to drive a Ford.
There is a part of me that wishes that Brooks' approach to software development were still possible. The emphasis on craft - on getting the design right without consideration of time and money - is very attractive. I often feel unprofessional because I know that all my designs and code are drafts that could do with more polish. But in most businesses, requirements rarely stand still long enough for a considered design to be possible. Executive decisions are often made in the heat of the moment and their later reconsideration can cause the strategic purpose of software to morph while it is still being developed. The best you can do is to keep up as best you can and accept that there will always be rough edges. In the modern world, it does not pay to take too much pride in one's profession, and that is a pity.
The Mythical Man-Month - Frederick P. Brooks, Jr - Addison Wesley, 1995
* * *
This book is regarded as one of the classic texts about software project management, an activity that is an increasing part of my day job. So I thought I had better read it. Sadly, "classic" it is not. Much of the information and suggested practices in it are hilariously irrelevant to the modern working environment (microfiche for project management documents, anyone?). That said, there are a few classic nuggets to be found, and even the ways in which it has dated tell us something about how the world of work has evolved since it was written. Not least that having women in IT is not just socially desirable, but may directly improve the chances of success of a software project.
Brooks is clearly rather an odd cove. There aren't that many technical books where the preface ends with an invocation to the glory of God. And although it is dedicated to his wife, she is the only feminine reference to be found in the whole thing. One gets the impression that IBM in the 1970s was as all-male as a monastery. Whether this is true, or whether Brooks just has an impatience with gender-neutral grammatical formulations, is not entirely clear. Though it's fair to say that his sexist title has a pithy memorability for which I can't think of a female-friendly alternative (The Paradoxical Person-Period? The Whimsical Woman-Week?).
His main point boils down to a law of diminishing returns in the assignment of human resources to projects. When a software development effort starts to go off-plan, the first instinct of a manager is typically to add extra developers to help get it back on track. But the disruptive effect of an extra member of the team - the additional personal communications needed to make them effective - means that a new developer can end up making the project even later than it would have been before. All projects also have "choke points" - specifically, analysis, design and debugging of specific components - which can only be sensibly be done by one brain at a time. Knowing when not to assign people to a project is as important as knowing when to assign them.
Brooks' solution to effective management is a highly hierarchical team with a "surgeon" (chief programmer) and "co-pilot" (secondary programmer) and a large support team of administrators, secretaries(!), editors, testers, toolsmiths and programming clerks who do everything not directly related to the primary code. For large products he advocates a number of such teams all co-ordinated by a systems architect. He says that consistency of design is key to an application's success and that this can only sensibly be achieved if a single person is responsible for the design.
To a large extent I agree, but the notion of the almighty Systems Architect to whom everyone else must bow down is quite ludicrously patriarchal. Yes, singularity of vision is important, but human frailty means that an architect will often get things wrong or will fail to articulate their design adequately to the other members of the team. The best human systems are more collegiate - they have checks and balances so that mistakes by individuals can be spotted and corrected by colleagues. This works better for everyone. Leaders are not paralysed by fear of doing the wrong thing and followers feel valued and empowered to contribute to the success of the product. Of course groupthink and responsibility-dodging must be avoided, but in my opinion designs by (small) committees are usually better than ones created by an individual working alone.
There is a valuable lesson to be learned from Brooks' analysis, however, and that is the importance of good and efficient communication within a software development team (to this I would add the importance of communicating and empathising with the ultimate users of the software - a subject about which Brooks has curiously little to say). Now I don’t think it is too controversial to say that personal communication is something that women, in general, do better than men. So it follows that having women on a development team is likely to increase its chances of success. Brooks cannot make this point because his vision is blinkered, but it is implicit in his analysis.
Brooks' approach has also been undercut by economic and social developments. In his formulation, a development team would consist of 20% programmers and 80% support staff. The only way to pay for such a team would be to charge a fortune for the product. But that is not the way of the modern world, where price is a key consideration for customers and generous people in the open source movement and the ground-swell of capable programmers from places like eastern Europe and India act to bear down on costs. Brooks want to build a Rolls-Royce, but most of us are happy to drive a Ford.
There is a part of me that wishes that Brooks' approach to software development were still possible. The emphasis on craft - on getting the design right without consideration of time and money - is very attractive. I often feel unprofessional because I know that all my designs and code are drafts that could do with more polish. But in most businesses, requirements rarely stand still long enough for a considered design to be possible. Executive decisions are often made in the heat of the moment and their later reconsideration can cause the strategic purpose of software to morph while it is still being developed. The best you can do is to keep up as best you can and accept that there will always be rough edges. In the modern world, it does not pay to take too much pride in one's profession, and that is a pity.