Facts and fallacies of Software Engineering.

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” ]

Published by

Anton

Hello! My name is Anton. I am a passionate project manager who loves digging deep into code. You can check my Github and CodeEval. Hopefully my thoughts on management can lead you to one or another good idea.