The mythical man-month

Would you call me arrogant for retitling this book as “Mythical technology no one cares for now”? You have the right to do so. However I want to provide some argumentation for that if it please ya.

To tell long story short – the main thesis of the title, that adding people to late projects will delay them even further is mentioned in the second chapter of the book. Until the 17th chapter you’ll deal with ancient stuff about OS/360 (what the heck is that?) and IBM 1771, Machine 881295, coding languages so ancient they make Greek Gods seem modern. I have no issues with people wanting to learn from the very basics. But generally this is not effective. If you want to dig a hole in your garden you go to the supermarket, buy a shovel and do the dirty work. You won’t, however first go and buy seeds, plant a tree, watch it grow, go to the mines, prospect the ore, process it, create the shovel blade, cut your tree (same procedure for the axe by the way?), make the handle, connect the blade with the handle and…finally dig!

Yes, you could do that, but it’s just not effective. You just rely on people who create this stuff for you. It’s important to have a basic knowledge (that a shovel blade made from paper might seem as a bad idea) but still you need other qualifications for digging a good hole.

Is this post just about nagging or will there be something constructive?

It’s the same with this book – not only it gives the reader such outdated information (ok, ok, it was written few years ago, 1974), but it’s also written so damn complicated and jumps from one extreme to the other – it’s either written too general (although I’m not the dumbest person I wasn’t able to understand) or so heavily loaded with detailed information about things one one knows they even existed without even explaining it!

You see, this is the main point – if this book should be an introduction it clearly lacks all introductional features as explaining material. If this book is a summarization of some facts… well I guess it was good back then, but now I don’t see the point of it. The mythical man-month suggests that this book is about people, about working with people but it’s just a practice report from over 40 years now. I might seem to brag here often about the release date, but you know what – other authors show that this is clearly not an issue at all, just take a look at DeMarco & Lister (if you haven’t read my article about their book – just skip the article and go buy their “Peopleware”)

TL;DR?

Let’s consider two quotes from the book:

Consider the linkage editor, designed to load separately-com- 
piled programs and resolve their cross-references. Beyond this 
basic function it also handles program overlays. It is one of the 
finest overlay facilities ever built. It allows overlay structuring to 
be done externally, at linkage time, without being designed into 
the source code. It allows the overlay structure to be changed from 
run to run without recompilation. It furnishes a rich variety of 
useful options and facilities. In a sense it is the culmination of 
years of development of static overlay technique.

and

The unexpectedly hard part of building a programming system is 
system test. 1 have already discussed some of the reasons for both 
the difficulty and its unexpectedness. From all of that, one should 
be convinced of two things: system debugging will take longer 
than one expects, and its difficulty justifies a thoroughly system- 
atic and planned approach.

You take the meaning? First quote – my wtf moments: what is linkage editor? Cross-references? Program overlays? Overlay facilites? Structuring to be done externally? There is a lot of information in this text. But is it useful?

Second quote – a hell lot of text for saying… debugging is hard?

My advise at the end, if you really want to read this book – skip chapters 4-13 and chapter 15 and 16. Just do it, you won’t miss anything you’ll require for a start of your career. Basically in chapters 18 and 19 (of the second revision) the author summarizes his own book, commenting own statements 20 years later (revision was published in 1995).

[schema type=”book” url=”http://www.amazon.com/The-Mythical-Man-Month-Engineering-Anniversary/dp/0201835959/ref=sr_1_1?ie=UTF8&qid=1412691597&sr=8-1&keywords=mythical+man+month” name=”Mythical Man-Month” description=”This is the official description from Amazon, don’t come hereafter and complain – I warned you! Few books on software project management have been as influential and timeless as The Mythical Man-Month. With a blend of software engineering facts and thought-provoking opinions, Fred Brooks offers insight for anyone managing complex projects. These essays draw from his experience as project manager for the IBM System/360 computer family and then for OS/360, its massive software system. Now, 20 years after the initial publication of his book, Brooks has revisited his original ideas and added new thoughts and advice, both for readers already familiar with his work and for readers discovering it for the first time.” author=”Frederick P. Brooks Jr.” publisher=”Addison-Wesley Professional” pubdate=”1995-08-12″ edition=”2nd Edition” isbn=”858-0001065793″ paperback=”yes” ]

Facts and Fallacies – trust them or prove them wrong?

Facts and Fallacies of Software Engineering is without a doubt s decent book. It could be even considered as a good book, but I – fully subjectively and emotionally – just cannot do it. While the main thesis can be summarized as following

Programming is too complex to be measurable, deal with it

and while the facts themselves are quite interesting, I can’t get rid of the feeling that the purpose of the whole book was to proclaim the great goodness of the author. It may sound a bit harsh, but reading on almost every page

as shown in blah-blah [Glass, 19xx] or stated in blah-blah [Glass et al., 19xx] etc. etc.

makes me wonder – is there anything besides author’s work that’s worth mentioning? Will ever a book have a chance to be regarded as a reference for our Robert Glass? I doubt that. Additionally a lot of “facts” are based upon own researches or researches of a very small groups, which is not bad per se, but makes statements like “list of derivative requirements grow by 50 times” seem not a great deal trustworthy. Why 50? Why not 49 or 20?

I don’t want to fully degrade the book since it’s nevertheless pretty decent and now I’ll explain why. The answer is pretty simple – some statements are indeed to such an extent obvious that they may be truly regarded as facts. A few of them I’d like to highlight here in a shortened and combined version.

Every project evaluation is made by false people and at wrong time without correcting the vector.

This is basically the essence of all failure. True is, most of the time the work is estimated by managers or even product owners without involving developers at all. In better cases teams play planning poker, but usually it is discarded because it takes so much time “we can’t afford to invest, better start earlier and give us just an estimation”. In 99.99% of the cases your estimation as manager will evolve into a… real value upon which everything will be based. Deadline? You said project will be done in 3 months, so deadline is now+3 months! No one will ever care to adjust the evaluation or, more correctly expressed, care to accept your changes willingly.

The difference between worst and best developers is a big gaping hole, the difference in their salaries, however, not.

First of all here we have numbers telling us (numbers lie, you know?) that the difference is up to 28 times – again, I’m not a big fan of such numbers, but the essence of the statement is quite true – you gain a lot by hiring best people, because the salary you’ll pay to worst people will come back to you twice – you’ll pay more at the end of the day, because you’ll need more of that sort of people and you’ll deliver mediocre products because those people won’t be able to produce good software.

Supporting your software will cost you up to 80% of invested capital.

Glass mentions numbers span between 40% and 80% and whether you agree or not with those numbers, we all can’t deny the fact. It’s simply true, that your every neat customer will come to you after project “is done” and demand – hey, can I have a button here, a function there? Trust me, and if you don’t trust me, trust Glass – this will eat, no, this will devour and annihilate your time.

[schema type=”book” url=”http://www.robertlglass.com/” name=”Facts and Fallacies of Software Engineering” description=”You can trust the facts blindly or try to prove them. Let this short summary be an introduction to this book.” author=”Robert L. Glass” publisher=”Addison Wesley” isbn=”5-93286-092-8″ paperback=”yes” ]

Keep in mind – the deadline is your pal

Usually there are posts and books (a great one though – “The Deadline: A Novel About Project Management”) about managing deadlines, however this post will be about setting them – even for yourself.

Are you nuts? Why should I willingly determine a deadline if there is no pressure from outside?

If you happen to be one of the more luckier people out there who don’t get stuck with deadlines from outside consider yourself still in the same boat. The answer is simple – there are always time limits. If someone says otherwise, slap them. A-l-w-a-y-s, meaning at any given point of time there is someone who will ask you after a few weeks/months/years

WHY THE HECK ISN’T DONE YET???!!

And believe me, you want to avoid that situation at any cost. So if you’re working in a tiny-shiny-fancy-nancy startup, realize – they will ask you. And sooner you get your project organized the better.

If nobody provides you any tools, information or cooperation at all, remember – where there’s a will, there’s a way. At the end of the day they paying you exactly for it – for you getting things done regardless of the “how”. So my advice – get yourself a few sheets of paper and a pencil, start a prototype, draw a silly face, a cartoon, then try to write down your project’s goal. Can it fit in one sentence? No? Think again. Eat. Sleep. Rave. Repeat. Try to think what components is the project made of – are there reocurring modules? Can you extract some pages?

Decomposition is the keyword

Work top down, from goals to tasks which can be estimated. This estimation gives you your ace card. The more time you got the deeper you should get, meaning if you have just a vague goal you could guess it as 5 months or 5 years, if you have 100 tasks each guessed by 4 hours, you get 400 hours, 200 working days meaning somewhat 8.5 months. Having such a value will give you a much better situation because it’s based on smaller estimations where even a 100% volatility won’t hurt much (the probability of having all 100 tasks estimated wrong by half is incredibly low).