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).

Peopleware by DeMarco and Lister

If there is one core sentence that could summarize whole book, it would be – even in the IT field most problems arise around people, not around technology. And you can solve those problems by addressing at people’s issues, not implementing another METHODOLOGY. This leads to the main concept of peopleware – caring for your team, trusting them and creating best conditions for creative work.

Well, it’s clearly a pity, that I read this book that late in my path as a PM, in fact if you want to join the journey, make sure to read it first! Don’t even bother reading further my summarization since it will be all like how great this book is. And indeed it is.

Simply said, just read this book and skip my post.

If it’s so simple, why are a lot of projects failing, why can’t we just make this book a METHODOLOGY, a standard for every IT company out there? Well, because it’s unpleasant. A hell lot of managers (including myself) love to operate with numbers, measure story points, velocity, team performance because they trust numbers more than feelings. You can explain a number, but in most cases you won’t be able to explain a feeling. And your boss won’t accept a feeling either. And your team won’t provide you any numbers, like – hey, I’m feeling down today because the loudness level raised by 20%, thus, lowering my productivity by 15%. And and and.

You should care about your people and create or try to create best possible environment for them (simply try to rhyme peopleware with peoplecare). Because there is no mass production in such an intellectual field of work. Coding is not like working along an assembly line. You will need a “flow”. It’s not trivial to get into the flow-state, it takes some time and every interruption will force you to leave the state.

If you need the shortest summarization of the book, here we go – find right (means qualified) people, infect them with your idea, create best possible conditions for their work, leave them alone.

Here are few total no-go’s that no one should ever do to his/her team:

  • Huge open spaces – no, no, no and again no. When your brain is working you need silence. That’s as simple as it is. People listening to music or other environment’s sounds can work too, but they can’t create new, alternative solutions, they can just do their routine work.
  • Engulf your people in beaurocracy  – just think over it – do your really need a daily report? If you answer is ‘yes’, think again. And again. And then again. If the answer is still ‘yes’ you haven’t found the right people you can trust.

Why do you even mind mentioning short phone calls and furthermore call such distractions evil? Are you out of your mind?

Do you like math? I bet you do, at least numbers, since we all love numbers. Let’s say there are two employees, both instructed to do one task, consisting of several sub-tasks and few random phone calls. Let’s even assume they require same amount of time to carry out the work and need approximately about 5 minutes to adjust between some interruption with just one slight difference – we will place a phone near the first employee while leaving the second one completely exposed to silence handing out the phone to him at the end.

[bs_row class=”row”]
[bs_col class=”col-xs-6″]

Subtask 1 – done in 5 minutes

Subtask 2 – done in 5 minutes

Subtask 3 – done in 5 minutes

Subtask 4 – done in 5 minutes

Subtask 5 – done in 5 minutes

Adjusting time – 5 minutes

Phone call 1 – 5 minutes

Phone call 2 – 5 minutes

Phone call 3 – 5 minutes

Phone call 4 – 5 minutes

Phone call 5 – 5 minutes

[/bs_col]
[bs_col class=”col-xs-6″]

Subtask 1 – done in 5 minutes

Adjusting time – 5 minutes

Phone call 1 – 5 minutes

Adjusting time – 5 minutes

Subtask 2 – done in 5 minutes

Adjusting time – 5 minutes

Phone call 2 – 5 minutes

Adjusting time – 5 minutes

Subtask 3 – done in 5 minutes

Adjusting time – 5 minutes

Phone call 3 – 5 minutes

Adjusting time – 5 minutes

Subtask 4 – done in 5 minutes

Adjusting time – 5 minutes

Phone call 4 – 5 minutes

Adjusting time – 5 minutes

Subtask 5 – done in 5 minutes

Adjusting time – 5 minutes

Phone call 5 – 5 minutes[/bs_col]

[/bs_row]

Holy cow – 95 minutes vs. 55 minutes – that’s an increase of almost 100%!

Now imagine what happens when a phone is always in reach of your employees’ ears (even if they don’t have to answer it directly, for every call you can add some adjusting time. Additionally, by all means 5 minutes is a value suitable for a very professional employee, for your more-than-average protege you may increase this value by 100%-200%.