I’ve recently been re-reading Fred Brooks’s The Mythical Man-Month for something like the fourth or fifth time. It’s one of those textbooks that’s so well-written and a joy to read it becomes a work of literature. It’s also a book that keeps on giving. Every time I read it I seem to get something new out of it, or learn some things that either I missed or glossed over on previous occasions. Here’s what I got out of it on my most recent re-reading.

Information Hiding

How I missed this before I don’t know, but Brooks was far from enthusiastic about information hiding when it was first proposed by David Parnas back in the 1970s. He was adamant that the programmer must know certain internal details about procedures, and called information hiding a “recipe for disaster” in the 1975 edition of his book. To be fair, Brooks wrote a full recantation in the second edition, admitting the advantages of encapsulation. I hope I can be as honest and gracious when I am persuaded to change my opinion.

The End of WIMP?

In a prediction of the future (written in 1995), Brooks presages the obsolescence of the WIMP style of interaction “in a generation”. He doesn’t elaborate how long a generation is (maybe it’s passed already?), but amazingly, after however long it lasts, he predicts that speech input will be the way to do things. This is a prediction I just cannot go along with, if only because I know that sitting in an office talking to my computer all day and being surrounded by others doing the same is not the way I want to program. Maybe some interaction models will evolve this eventually (the computer-driven home entertainment system comes to mind), but I can’t help thinking about mobile phones, which have had voice recognition capabilities for a while now. Still, all I ever see are people thumbing their way through their phones.

Small-issue Meetings

A smaller thing I noticed was Brooks advocating a semi-regular meeting where only small issues are discussed (every few months in his advice). I’ve often found it a nagging problem that having a priority-driven task-list risks leaving smaller issues undone as the larger ones monopolise our attention. Despite their merits, approaches such as Scrum and feature-driven development leave me unsatisfied in this regard. Sometimes addressing a bunch of smaller issues can be a better thing to do than taking on a single biggie; forcing consideration of this through regular ‘small issue’ clear-outs intrigued me as an idea. I only worry about the levels of enthusiasm in a meeting like that.

Religion

This wasn’t first time I’d noticed the religious influence in the book. It’s hard to miss it, but before my most recent reading of Mythical Man-Month I had zero interest in religion and the references mostly passed me by. I’ve since become more knowledgeable about it, if only as a stupefied outsider, so I am much more conscious of when Brooks (an evangelical Christian) uses religious references. For example, he cites the comparison of three stages of creativity with the Christian trinity. He uses the cathedral at Reims — “glorious” because the builders chose to sacrifice their own ideas for the purity of its design, thus “the result proclaims not only the glory of God, but also His power to salvage fallen men from their pride” — as an argument in favour of conceptual integrity. Brooks’s proposal for achieving conceptual integrity is to empower one team-member as the “architect” and thus be responsible for all design decisions — a single designer, so to speak.

This put me in mind of Charles Simonyi as described by technical journalist Robert X. Cringely. Simonyi, a Microsoft alumni, developed a software management technique called metaprogramming, which Cringely referred to as the collective farming of software development. Cringely attributed the nature of metaprogramming to Simonyi having grown up in communist Hungary and said that he was unconsciously emulating the rigid structure of the society in which he was raised. Brooks’s ideas are quite different, but I wondered if the same was true of him and his perspective of software development management, in which a powerful architect creates and shapes new worlds, assisted by a team of saints and angels.

I’m only semi-serious with this one; it’s surely much more complicated than that. But do we all instinctively copy the same ideas from the culture in which we’re steeped?