Yostivanich

The Myth­i­cal Man Month is one of those sem­i­nal works of soft­ware engi­neer­ing that praise is heaped upon and quoted at most if not all soft­ware firms. The book itself is per­haps most famous for pop­u­lar­iz­ing the rule that “adding more pro­gram­mers to a late project makes it even later”. This how­ever is not the only con­clu­sion to be gath­ered from this book.

The Sum­mary

The book should per­haps be most praised for being writ­ten in a man­ner that the engi­neer in me can get behind. Short and fast chap­ters with not a lot of fuss of dou­ble telling a point after it has been made. Includ­ing a bul­let point review of the book, it is a short 300ish pages long. Per­haps the largest com­plaint of the book is that the focus of the book is upon sys­tem or what is now known as embed­ded pro­gram­ming. That being said there are a great many points to be gath­ered from the book.

The first is that there are sev­eral dif­fer­ent types of pro­grams, sim­ply a pro­gram, a pro­gram­ming sys­tem, a pro­gram­ming prod­uct and finally a pro­gram­ming sys­tem prod­uct. Only the last is one that is the goal of most pro­gram­ming teams. The first is essen­tially some­thing that the pro­gram­mer can use and build in the course of a few days or weeks of effort. The sec­ond and third are required inter­me­di­aries to the fourth but mov­ing in oppo­site direc­tions. A pro­gram­ming sys­tem is where a pro­gram becomes a part of a larger project. This requires the pro­gram to man­date all input and out­put to be seman­ti­cally valid and cor­rect, to be on a well-defined bud­get of resources (be they com­puter time/memory and i-o lim­i­ta­tions) and to play well with other program.

The pro­gram­ming prod­uct requires a vast suite of test cases so that other pro­gram­mers may rely upon it and through doc­u­men­ta­tion so that oth­ers may extend it’s fea­ture set. Each of these two inter­me­di­ary steps requires in the authors words “three times the cost of the ear­lier one”, so that together the pro­gram­ming sys­tem prod­uct “costs nine times as much”.

Still inside of the first chap­ter, do we get the next great rev­e­la­tion; pro­gram­ming is a fun and abstract art. This leads to its own set of prob­lems, least of which is the abstract part. Per­haps the great­est of these is the require­ment of per­fec­tion demanded from com­put­ers. The list of prob­lems quickly grows in the next few para­graphs, being at the whim of oth­ers deci­sions and oth­ers goals, depend­ing upon oth­ers per­fec­tion for a pro­gram­mer rarely works alone in all aspects of a project, the design is more fun that actual imple­men­ta­tion, debug­ging becomes more dif­fi­cult the fur­ther one goes, and finally that rarely does it seem to be ahead of the curve more often than not it feels that the project is already obso­lete before completion.

I love the image that the author weaves here of Soft­ware Engi­neer­ing being a tar pit and him try­ing to “lay some board­walks across the tar”.

Sched­ul­ing soft­ware is a noto­ri­ously dark art. The author brings forth a sim­ple and basic rule for divid­ing up the time on a soft­ware project.

• 1/3 Plan­ning
• 1/6 Cod­ing
• 1/4 Com­po­nent and early sys­tem test
• 1/4 Sys­tems test, all com­po­nents in hand

The next bit is the most famous of the con­clu­sions from the book in which the author dis­cusses how adding more peo­ple to a project doesn’t make it any sooner to com­ple­tion, if any­thing slows down the project over­all. There is the mat­ter of both train­ing these new engi­neers on the inner work­ings of the project before they can even be brought into work­ing on the project on any­thing approach­ing a full-time basis, the next is that as you add more peo­ple there develop more lines of com­mu­ni­ca­tion and more time to del­e­gate and split tasks into man­age­able pieces for each per­son to work on. Essen­tially far eas­ier for two peo­ple to meet and decide on two parts of the project to tackle, far harder for three, four or five peo­ple to meet and del­e­gate the project into x num­ber of pieces for each to work. Espe­cially for the task to be divided in such a way that you are both account­ing for one’s abil­i­ties and try­ing to time the project so each fin­ishes at roughly the same time.

The author com­ing from the dis­cus­sion of how more peo­ple on a project leads to an over­all slow­down in the project argues with more data than any other sec­tion for a “sur­gi­cal team” to tackle projects, even those ridicu­lously large ones to be split into man­age­able por­tions for sur­gi­cal teams to take on as opposed to “hog-butchering team”. Essen­tially for a coor­di­nated effort by one or two pro­gram­mers with all oth­ers act­ing in sup­port of those one or two programmers.

The vast major­ity of the rest of the book espouses and stresses these points in some way or another. From espous­ing that a good design (note design here terms of design of the archi­tec­ture not design in look and feel) can only come from a sin­gle or extremely lim­ited num­ber of per­sons. That archi­tects of sys­tems of a sys­tem have a ten­dency to over design to achieve com­plete inter­op­er­abil­ity and exten­si­bil­ity. Assign­ing value to both the num­ber of bytes and time needed for a func­tion to com­plete is a good way to limit over design.

There must be both for­mal and infor­mal level design doc­u­men­ta­tion. Inter­com­mu­ni­ca­tion and orga­ni­za­tion are require­ments for even a decent project to take flight not just among team mem­bers but across all teams. The author argues for daily meet­ings for all team mem­bers with weekly inter-team meet­ings. He also argues for some form of a project work­book to col­lect all changes and thoughts of the team mem­bers so that any­one review­ing or test­ing a sec­tion has com­plete access to all knowl­edge of that sec­tion on the spot. At the same time the author argues for all team mem­bers being required to see and read the work­book, at a later date he becomes con­vinced oth­er­wise and instead stresses that the infor­ma­tion be made avail­able but not in essence required read­ing. Plan for throw­ing away an ini­tial ver­sion of the project. Iter­ate quickly on a project, cre­ate a work­ing ver­sion as quickly as pos­si­ble and keep up it’s work­ing state through­out the course of the project. A project does not all of sud­den become late but rather over the course of one piece tak­ing longer or one day of missed meetings.

Doc­u­men­ta­tion while hated is a really impor­tant fea­ture for a good project, not just for the cus­tomer but for pro­gram­mers to know the why behind a piece of code. Re-using or pur­chas­ing that which has pre­vi­ously been done to save lots of time and effort than in effect re-creating the wheel. Adding func­tion­al­ity to soft­ware in a piece-meal fash­ion, rather than all at once.

It’s all in all a long list of points for such a short book and per­haps most inter­est­ing for being such an old book espouses some ideas that I would have thought not in prac­tice until much later.

The Review

Over­all won­der­ful to read, super fast and easy to read. Lots of exam­ples and data points from basic research to ana­logues and one-off sto­ries to pro­vide force behind each point. The major­ity of the points I would take lit­tle to no time to cri­tique except for that it focuses heav­ily on sys­tems pro­gram­ming and hence not in an area that I find myself (and prob­a­bly most mod­ern pro­gram­mers) work­ing in. Lit­tle effort to none is made for focus­ing on the actual usabil­ity of a project beyond that of other pro­gram­mers, whereas most Soft­ware Engi­neers find them­selves writ­ing code that a nor­mal human being will inter­act and deal with. The book also devel­ops a ten per­son strong team with just one or two peo­ple actu­ally devoted to writ­ing code. This seems more than a bit of overkill. I would sug­gest some­thing much closer to the 37Signals plan, one man­ager, two pro­gram­mers, one designer and one tester. Per­haps my small­est cri­tiques is the focus on “man” hours as opposed to per­son hours, also the lit­tle one off here and there of using a reli­gious idea as proof for a soft­ware engi­neer­ing plan. For instance, in the bul­let points on using two core pro­gram­mers on a team the author makes a foot­note of “Note God’s plan for mar­riage”. Minor annoy­ances I admit but they detract from an other wise well writ­ten and devel­oped ideas.

I would rec­om­mend this book to not just Man­agers of soft­ware projects but also to the pro­gram­mers under their lead­er­ship in the hope that they under­stand bet­ter the dif­fi­culty in cre­at­ing an out­stand­ing “pro­gram­ming sys­tem project” and quite pos­si­bly how to build a bet­ter main­tain­able project.