StackOverflow DevDays - (Talk 5 of 6) - Greg Wilson's Bits of Evidence

This post is about Greg Wilson's presentation of Dev Days.

Enjoy

Bits of Evidence

Hi,

There were no title or subject specified on the official DevDays program for Greg Wilson's talk. And just before the presentation, Greb Wilson was a complete stranger to me!

It didn't took long to see that he have a natural talent to communicate. I almost had a heart attack because the transition from asleep to all ears was so quick! (I'm always sleepy after lunch, especially during a long presentation of something you already know...)

The presentation started with a rather long story, that I missed some parts thanks to my English. May I remind you that, at that moment, I still have no idea about the presentation's subject! After his story, he mentioned a couple of examples of some inventions or discoveries that are generally accepted today but were controversial at the time of their appearance. He then made a parallel with those examples and with the methodologies we employ to build softwares today. Why choose this methodology? Are there any rigorous studies out there? Are the proofs made?

Finally it became clear that the presentation was about the performance of the methodologies we use to build softwares and the way we benchmark them. He insisted on the fact that, some methodologies are difficult to believe and adopt because 1) there are simply not enough proofs about the performance claims and 2) many people would rather fail than change! About number one, there are numerous studies today to back some claims but are often too biased or not serious enough. On the other hand, if no one believes in something because of a lack of studies, it doesn't make it wrong either. I read a little on the subject recently and real studies are hard to conduct because of the costs involved. Which company would be ready to loose ten employees for three month to conduct an experiment that maybe won't bring any benefits on their productivity in the future?

After elaborating on the controversy on how studies are conducted, Greg Wilson came with some examples of serious studies and their results. I'm going to list them and conclude after that. I'm going a little fast here because really, I can't write a blog post to truly express what was being said! Here's the list:

• The 2 biggest cause of project failure: poor estimates and unstable requirements (van Genuchten et al, 1991)
• For every 25% increase in a problem complexity, there is a 100% increase in solution complexity (Woodfield, 1979) On the other hand, a 25% decrease in the functionalities lets you deliver the project in half the time
• If more than 20-25% of a component has to be revised, it's better to rewrite it from scratch (Thomas et al, 1997)
• Rigorous inspections can remove 60-90% of errors before the first test is run (Fagan 1975)
• The first review and hour matter most (Cohen 2006)
• Maintenance is 40-80% of the cost of a software project. 30% of that time is spent figuring out how stuff works (Boehm 1975). 60% is enhancements (Glass 2002)
• Small changes have a higher error density than large ones (Because they require the same level of understanding) (Basili and Perricone 1984)
• Error cluster according to a 80/20 rule (Boehm et Basili 2001)
• A system reflects the organizational structure that built it (Conway's Law) (Herbsleb et al 1999)

The previous one's a personal favorite of Greg Wilson. Well, I have to admit it, that's a great one. But my all-time favorite is:

• Physical distance (between colleagues) doesn't affect post-release fault rates. Distance in the organizational chart does (Nagappan et al 2007 & Bird et al 2009)

In the end, there's no blog post that can match the live presentation. After, everyone stood up and started talking to each other, hope in their eyes... that was great. But you can't really be as convincing as Greg Wilson when you try to change things for yourself. Why ? That's not your job. You're paid to be a programmer. Honestly, after earing Greg Wilson, if you try to go to your boss and say something like "hey maybe we should review our methodologies", either you deserve my respect or I pity you for loosing your energy. Face it, you're not armed to engage in such a talk with the upper management. What you are going to do? Throw slides of the presentation on your boss' desk? That's not serious. After ten years I've seen it all. On every project, there's always an "exception" that prevents us to work as we should be. And when you won't be able to bring arguments against a counter-productive idea because "you just know", well, next time come up with some gigabytes of evidence! Well I say in my 10 years, it wasn't all that bad :)

I'm putting time and effort on this blog and having you here is my reward. Make me feel better and better everyday by spreading the love with the buttons below! Also, don't hesitate to leave a comment. Thanks for reading!

PS. I could have also named this post "What happens in DevDays stays in DevDays"

Related Articles

• StackOverflow DevDays - Packing my stuff
• StackOverflow DevDays - Opening Keynote with Joel Spolsky
• StackOverflow DevDays - (Talk 1 of 6) .NET MVC
• StackOverflow DevDays - (Talk 2 of 6) Python
• StackOverflow DevDays - (Talk 3 of 6) Fogbugz
• StackOverflow DevDays - (Talk 4 of 6) - jQuery
• StackOverflow DevDays - (Talk 6 of 6) - Ruby
• StackOverflow DevDays - Conclusion

See ya