What We Actually Know About Software Development, and Why We Believe It's True

A very good presentation on how we can make the field of software engineering better by Greg Wilson: http://vimeo.com/9270320. He also brings up some thought provoking data-points:

Greg Wilson - What We Actually Know About Software Development, and Why We Believe It's True from CUSEC on Vimeo.

From the slides in the presentation:

• Most errors are introduced during requirements analysis and design. Not during writing and debugging. The later a bug is removed, the more it costs to remove. (Boehm (1975))
• For every 25% increase in problem complexity, there is a 100% increase in solution complexity. It's non-linear because of interaction effects.  (Woodfield (1979))
• The two biggest causes of project failure are poor estimation and unstable requirements, neither of which seem to be improving in the industry as a whole. (van Genuchten (1991))
• If more than 20-25% of a component has to be revised, it's better to rewrite it from scratch. (Thomas et al. (1997))
• Hour for hour, sitting down and reading the code is the most effective way to remove bugs. It's better than running the code and better than writing unit tests. 60-90% of all errors can be removed before the very first run of the program. BUT, all of that value comes from the first hour by the first reviewer. You can only read code for an hour before your brain is full - only a couple hundred lines of codes depending on skill / practice. This means we should have small patches and changes. (Fagan (1975))
• The architecture of the system reflects the organizational structure that built it. (Herbsleb (1999))
• Physical distance between a team of developers doesn't affect post release fault rate. Distance in the org chart does. Thus, it's fine to have people remote as long as they are on the same team, just don't put developers working under different people on the same project. (Nagappan (2007) & Bird (2009))
• No code (or other) metrics that were published before 2001 have any correlation with post-release error rate beyond that predicted by source lines of code (SLOC). (El Emam (2001))
• When estimating the time it will take to complete a project the only thing that matters in the spec for the project is how long the writer of the spec thinks it will take (ie. the anchoring effect from psychology). "All work done to date on software estimation is pretty much pointless. All the engineers are going to give us back is what we want to hear." (Aranda & Easterbrook (2005))