skip to content W3C SVG

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

2011-12-11
  • Greg Wilson
    • 2010-02-07

    • The claim that a good programmer is 10, 28, 40, or 100 times as productive as an average one is based on flawed data.

      • a 1960’s study on 12 subjects (mostly self-taught because it was the ‘60’s) over the course of an afternoon’s worth of programming.
      • a 1980’s study on 54 programmers where the slowest programmer took 63 minutes.
      • Note also that this describes the max spread not distribution.

    • Look up the work of Lutz Prechelt to see about productivity variation between programmers, effect of language/framework.

    • You will produce roughly the same amount of text per hour regardless of which language you work in.

      • Does this imply you should be working in the highest-level language you possibly can?
        • Well, sorta: “Platform independent programs have platform independent performance”

    • From the 1970’s (but replicated in other studies in other domains):

      • Bugs introduced in design phase
      • Most errors are introduced in requirements analysis and design phases
      • The later the bugs are removed, the more expensive it is to remove them (orders of magnitude)

    • Problem complexity increases by 25%, solution complexity increases by 100%.

      • If I can cut the problem down by 20%, I can halve the time it will take.

    • Poor estimation and unstable requirements are the biggest problems

    • Claimed by Boeing but unreplicated

      • If you have to rewrite >= 20-25% of a component, it is less work to rewrite it from scratch.

    • Rigorous inspection of code can remove 60-90% of bugs before the code is first run

      • i.e., code review is the most effective way to remove bugs
      • The first reviewer, for the first hour, is by far more effective
        • i.e., by the 2nd hour, reviews/reviewers become less effective. So keep patches small.

    • Conway’s Law: A system reflects the organizational structure that built it

      • meant as a joke, appears to actually be true.

    • Data (email, chatlogs, etc.) from the dev of Windows Vista

      • physical distance doesn’t impact post-release fault rates
      • distance on org chart DOES impact post-release fault rate