A few weeks ago, the Business Bro and I got together to discuss this book. Longtime readers, I’m sure, were not surprised to see this effort go up in smoke. My apologies, reader, for all the time wasted.
It occurred to me recently, though, that our conversation was a microcosm of the book’s larger point. As new members are added to a project team, the communication burden will increase. In these cases, the challenge for leaders is to structure the work so the benefit of added manpower is not offset by the increase in communication cost.
This sounds like a simple enough job, I thought, but there are a number of reasons why software development projects struggle to maintain this balance. One reason is the way management demands a skill set entirely different from programming. Software engineers of any value are perfectionists. Otherwise, the programs they write will never run correctly and all their time will go to debugging!
On the other hand, management is work that does not suit the perfectionist. A good manager must constantly make decisions about trade-offs. By definition, the manager’s job is to choose the best set of decisions from a set of imperfect options. Software project mangers who are promoted into the job after excelling as engineers are at a disadvantage because the perfectionism they relied on to reach maximum performance in the programmer role is going to hurt their performance in the manager role.
A specific area where these ‘perfectionist managers’ struggle is when designing the ‘second system’. Often, the second system is intended to replace a no-frills first version. The idea of a second system is exciting for architects because it is an opportunity to include the many ideas for neat designs, features, or capabilities they stored away during the initial design. (By reducing the complexity of the first design, the project was more likely to come in on time or under budget.)
However, overloading the second system with these features is likely to lead to delays in testing. It will also leave less room for other engineers to contribute their own ideas or follow creative tangents during the design process. In many ways, an architect must exercise more self-restraint in the second system than was exercised in the first system. For managers who were promoted into the wrong role, the second system often reveals how far removed the new job is from the career path they would actually find more rewarding.
One up: I liked the many nuggets Brooks sprinkles throughout this book. These insights drew on repeated themes from the history of computer science to explain common errors or make predictions about the future of the field.
A common idea was how bad managers often revealed their ineptitude through their excitement for The Next Big Thing. One common mistake such managers tend to make is to overestimate the long-term effects of a major work process shift. A transition to a higher-level language might initially bring strong returns. But over time, it becomes evident that the first problems solved after the change were also the ones with the most value. The remaining problems are likely to return less and less value over time. At some point, another big shift will make it possible to pursue more high-value projects. But here, the cycle starts anew. At some point, the practice of making shift after shift will compromise the long-term potential of the team.
The predictions Brooks made about voice technology intrigued me. In the early days of the Alexa Age, it seems to me like there is a lot left to figure out. Brooks, however, came off to me as fairly certain in how he expected voice technology to work with computers. His thoughts were based on simple logic: since the number of objects available to a computer is theoretically infinite while the number of actions a computer can take on a given object is limited to a set of defined functionalities, voice technology will eventually replace functional commands while pointing will remain the norm for identifying objects.
Of course, Brooks’s prediction is likely to apply for either novice or expert users. As he himself points out, most systems are designed with parallel functional features catering to each type of user. In today’s version of Excel, for example, the mouse allows the novice to do everything an expert can do on the keyboard. The future of voice technology might work the same way: a novice user will have the option for voice technology to identify as well as act on objects while the expert will remain content to use the keyboard to more quickly specify objects (examples here including difficult to pronounce objects, those with homonym names, etc).
One down: I got a little lost in some of the technical details here. Brooks seems down on the flowchart concept and suggests that a more reliable way to understand a system is to study the table structures. Why the hate for flowcharts? How else would a lay user know where the data came from?
He also points out how strategic breakthroughs derive almost exclusively from new algorithms and recommends redoing representations of data or tables in order to find these. Huh?
He also makes reference to certain methods for reducing the demands on debugging. Specifically, he suggests using syntax such as IF/THEN/ELSE, LOOP WHILE, or CASE to break up a program into a more easily controlled structure. Again, I could make neither heads nor tails of these ideas.
I was surprised to find such technically detailed writing in a book I was told focused strictly on project management. But then again, I was told these things by The Business Bro - I assume he has no idea what these things mean, either.
Just saying: I got the sense that programmers often worked late at – or perhaps all the way through – the night. Brooks points out how this mentality reflects the efficiency of thinking for a long, unbroken spell. He also notes how programmers generally report that, on average, half a workday is wasted by various non-programming responsibilities such as meetings or documentation.
Putting these two observations together reminded me of what I learned when I studied the various routines of famous writers. Most seemed capable of writing for between two and four hours a day. However, almost all of them did this in one block of time. It wasn’t like Hemingway wrote chapters of The Old Man and The Sea in the five-minutes spaces between his daily errands, you know? He just stood there, had his drink, and went on and on about the Great DiMaggio until he was done…
If the general lesson is true for programming, a good manager would structure the workday so that the administrative demands of the job came at times entirely separate from a daily stretch of long, unbroken time set aside solely for focused programming work.
