Sarà anche considerato un social network noioso e prevalentemente ad uso e consumo di imprenditori e venture capitalist, ma su Quora trovo spesso contenuti molto interessanti. Tra le tante domande pubblicate, mi è balzata all’occhio quella dal titolo Why are software development task estimations regularly off by a factor of 2-3?.
Particolarmente divertente ed interessante la risposta di Michael Wolfe, che utilizzando la metafora del viaggio spiega quanto sia facile fare stime totalmente sbagliate:
Holy shit! We are starting day 5 of a 10 day trip and haven’t even left the Bay Area! This is ludicrous! Let’s do the work to make an accurate estimate, call our friends, probably get yelled at, but get a realistic target once and for all. My friend says, well, we’ve gone 40 miles in 4 days, it is at least a 600 mile trip, so that’s 60 days, probably 70 to be safe. I say, “no f–ing way… yes, I’ve never done this walk before, but I *know* it does not take 70 days to walk from San Francisco to Los Angeles”.
In molti casi le stime falliscono perché sono il prodotto di una negoziazione tra sviluppatori e management, con i primi che tendono in modo difensivo a sovrastimare e il secondo che per comprensibili motivi economici o di time-to-market ha il desiderio di tagliare i tempi, ignorando però l’intrinseca complessità del processo di sviluppo software. In tutto questo, la vittima sacrificale è quasi sempre la qualità del software che viene prodotto.
Non sarebbe forse più opportuno usare come metrica per valutare il successo di un progetto di sviluppo la qualità del software prodotto piuttosto che quella del tempo di realizzazione?