Monday, September 10, 2007

The Mythical Man-Month: Why I Like Specs

So I've been reading a lot about project management and better ways to architect applications lately; design, process, code organization and interaction, and the like. One of the classic books out there that every one should read is "The Mythical Man-Month".

I'm sure we're all familiar with the little gem "nine women cannot have a baby in one month." But TM3 goes on to explain why creating a software application is more like creating a baby and less like building a bridge, at least as far as the additional woman-power goes. People are not interchangeable; visions are inconsistent, misunderstood, or incompatible; ramp up time must be accounted for; etc.

The book explains some ways that software design and implementation can be scaled up to teams of a thousand if need be without conflict of vision getting in the way. There are many processes and responsibilities that each person on a team has that allows them to work together without that conflict becoming a problem. Of particular immediate interest to me is the need for written specifications. "Why would you write about the importance of written specs? Everyone knows you need them, don't they?" Right.

"The manual is the external specification of the product. It describes and prescribes every detail of what the user sees... The manual must not only describe everything the user does see, including all interfaces; it must also refrain from describing what the user does not see."

All I can say from personal experience is that not following this wisdom causes problems. It is hard enough for one individual to have a vision of what your product should be. If that vision is not documented, it can not be implemented truly. If the visionary attempts to implement all of the vision on paper, as mock-ups or in code, there will never be enough time to complete the implementation. Divide the responsibilities and communicate.

Addendum 9/13/2007:

After reading a bit more of the book I have found that there are some chapters that are truly outdated. I would still recommend reading the book however. It is fairly easy to identify the sections that are aging; they usually contain a reference to OS 360 or some other decades old system. Still, it is a useful exercise to contemplate those sections to see how they apply to the present day.

Most of the concepts presented are still relevant. The examples are not necessarily as meaningful as they once were and the solutions presented are usually either outdated or never came into wide acceptance in the first place, so it is interesting to draw parallels to the solutions that exist today or to dream up a solution if one was never found.

There are a couple of chapters that just don't seem relevant to the general programming population of today though. The chapter on size limitation seems particularly quaint. While there may be some situations where developers of embedded devices still need to constrain the overall size of their software, I doubt any OS, web or intranet developer has been seriously constrained by byte limitations anytime recently. Not that we don't try to write code as concisely as possible, but legibility and maintainability are usually the primary goals.

Still a great book to read.

No comments:

Post a Comment