Book review: How to measure anything

(20.02.2012)

Few books can fill the category MUST READ. ”How to measure anything:” by Douglas W.Hubbard is on of these without doubt.

Here I want to share some interesting points I’ve found in it, without pretending to offer a solid link among them. But first some (personal) considerations.

Nowadays it seems that mathematical skills are very strong just after the graduation (of course I’m talking about ICT fields), then after some years of “coding” those skills are not practiced so much… and they literally dry up. It’s not uncommon to find a middle project manager (coming from coders/analysts) with economics, mathematical, statistical knowledge not well “established” or, better said, not practiced.

In some ways this book reflect this status quo and offer a solid knowledge about measurement, risk calculation and decision making from a managerial point of view. Studying and implementing CMMI I can find the same really needs expressed in PSP and TSP approaches.

Ok, now let see the book content.

Some pillars:

• what we generally label as “intangible” can - actually - be measured
• first we have to define the problem
• to measure == to reduce the uncertainty

Literally everything can be measured, even the most “intangible” ones. Three wonderful examples:

• Eratosthenes “measured” the Earth circumference 200 years BC
• Enrico Fermi was famous also for his joke about the estimation of piano tuners in Chicago
• Emily - the younger scientist publisher at 10 yo - dismissed the real efficacy of a “therapeutic touch”

Some clear definitions:

• the concept of measurement: definition of measure
• the object of measurement: what we want to measure
• the measurement methods: procedures and empirical observations

Very practical - and an effective “mantra” throughout the whole text - is the definition of measurement:

a set of observations that reduces the uncertainty where the result is quantitatively expressed

A clarification chain can help us:

1. if it matters then is observable
2. if it’s observable then it is by means of a quantity (or a set of possible values)
3. if it’s observable by a set of possible values then it is measurable

Four useful things to remember when faced with a measurement issue:

1. your problem is not so unique
2. you have more data than you need
3. you need less data than you believe
4. there is a useful measurement easier than what you really believe

First you have to clarifying your measurement problem; here are some questions:

1. What is the decision we have to support?
2. What actually is the objective of our measurement?
3. Why such a objective is so important for our decision^
4. What we know now about the objective?
5. What is the value of further measuring it?

Why an information is valuable for our business?

• it reduces the uncertainty of a decision that has economic consequences
• it influences people, with economic consequences
• it have value by itself

The cost of a wrong decision is equivalent to the difference between the decision and the best possible alternative (= the one we take in presence of perfect information).

Decomposition and reality sampling (spot, serial, clustered) can being really useful tools.

An interesting point is made “against” human judgement. As human beings we are not perfect, rather, we are really biased “brains”. Take into account this considerations when faced with “expert field” estimations.

Finally the author summarize his universal measurement method: the Applied Information Economics.

More info about the book can be found on the companion website.

On Products selection

(01.12.2011)

Often we face the problem of selecting a right product for us (middleware, utility programs, COTS, and so on). What should we do in order to make an informed and managed choice? Here I’d like to propose a little no non-sense approach.

Basically we need to know what we want, what are our needs. Then we can collect characteristics and factoids about the solution the market provides. It’s worth noticing that at this point we select only the products that could match our needs, and nothing more (hopefully). Now the question become “how much well do they match our needs?”.

Now, for each selected product, we can study it, prove it and collect data to analyze its behaviour: for each features we can assign a score (eg: from 1 to 5). Using sandboxes can also help us to refine the previously done needs analysis.

Of course features/needs are scored too: we don’t give to all of them the same importance. So each scored features is also weighted.

At this point we have a score for each product: we are able to make an informed choice with a little qualitative analysis. A (little) time worth spent!

To summarize:

1. features and needs analysis (= WHAT we need)
2. products gathering (= what COULD match my needs)
3. products analysis and scoring (= HOW MUCH do they match, and need analysis refinement)
4. weighted choice (= THE best for us)

Some example of characteristics:

• product age (more stable, young, not well tested/adopted)
• cost of installation, education, maintenance and operations
• how “stable” is the product owner (company or open source community)
• available documentation (generally easy to evaluate)

Simple, but often forgotten!

(photo credits Marzacas)

IAD2011 follow up

(21.11.2011)

As stated before this year edition of Italian Agile Day was dense of interesting talks. For detailed comments for every talk - and links to slide - see here.

Italian Agile Day 2011

(11.11.2011)

On 19.11.2011 there is the 8th edition of the Italian Agile Day, an event rich of interesting talks (26) about Agile, XP, Scrum, UX.

Participation fee? It’s FREE!

Target audience? Managers, Developers, Project leaders, Coaches… everyone!

SCM rules

(31.10.2011)

SCM (Software Configuration Management) tools are considered a cornerstone for every good software production environment today. Despite that a lot of problems can be introduced: branches messing, lack of policies and purposes.

In his excellent paper Henrik Kniberg show us some simple rules in order to avoid main problems. Here I don’t want to just repeat the rules, rather I’d like to show how important, appropiate and useful are simple rules.

We have some goals: (1) we want to fail fast so code conflicts and integration problem pops up near the event that caused them; (2) there should be always something releasable (within a good definition of “done”); (3) rules and this “mini process” must be simple, so team(s) can’t avoid them.

Rule: each branch in SCM repository has an owner and a policy.

The owner unsures the policy is applied and the branch is coherent with its purpose. The policy describes what kind of code goes in the branch. That forces also to avoid braches proliferation without any meaning: need a branch? Ok, but what is the purpose, the policy, the owner?

Trunk is the Done branch (can release at any time)

Rule: whoever touch the Trunk is responbile that everything works well (previous functionalities included!)

Development branch: code compiles without errors, all unit test passes, builds happean successfully

This ensure in this branch only tested code is allowed: simple and clean. This forces also to synchronize often with the Trunk in order to lately discover that we have to recode something (interfaces change, new classes, …).