About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.
Send comments to:
keithray@mac.com
| For Agile Training, eLearning, or Coaching contact: |
| Industrial Logic, Inc. |
| 866-540-8336 (toll free) |
| 510-540-8336 (Berkeley, California) |
| Links |
| xpminifaq |
| Résumé |
| “Adopting XP” Article 2002 (pdf) |
| “ Refactoring” Article 2006 |
| AYE Conference |
| Lucien W. Dupont |
| Elisabeth Hendrickson |
| Johanna Rothman's Managing Product Development |
| Brian Marick's Exploration Through Example |
| Esther Derby's Insights You Can Use |
| Laurent Bossavit's Incipient(thoughts) |
| Dale Emery's Conversations with Dale |
| Martin Fowler's Bliki |
| Creating Passionate Users |
Archives
Subscribe
RSS Exploring Solution Spaces XML
2006.Jul.08 Sat
Responding to Bruce Eckel's blog post Programming as Typing, where Bruce tries to get across the idea that programming is more about the programmers, rather than the act of hitting keys on a computer's keyboard. And that reasoning about programming practices is often based on fundamental, unproven (or even wrong) assumptions. Two quotes from Bruce: (emphasis is mine)
It may not even be possible to prove things logically when it comes to programming. So many of the conclusions that we draw this way appear to be wrong. This is what I like about the book "Peopleware," [by Tom Demarco or Larry Constantine?] and also "Software Conflict 2.0" [by Robert Glass] that I'm now reading. These books point out places where we operate based on what seems perfectly logical, and yet is wrong (one of my favorite studies in "Peopleware" shows that, of all forms of estimation, the most productive approach is when no estimate at all is made).
I think the essence of what the agilists are doing is a perfect analogy to the discovery of the scientific method. Instead of making stuff up -- and if you look back at all the "solutions" we've invented to solve software complexity problems, that's primarily what they are -- you do an experiment and see what happens. And if the experiment denies the arguments you've used in the past, you can't discard the results of the experiment. You have to change something about your argument.
Isaac Gouy mentioned two papers that provide statistical support for the effectiveness of some of the common practices of agile methods.
Quoting the blurb here about a study of 29 projects at 17 companies: (emphasis is mine)
Recent research from Harvard Business School professor Alan MacCormack and colleagues proves a theory about software development that has been gaining adherents for some time: The best process is an evolutionary one. Focusing on the area of Internet-software development, the researchers uncovered four practices that lead to success: an early release of the evolving product design to customers, daily incorporation of new software code and rapid feedback on design changes, a team with broad-based experience of shipping multiple projects, and major investments in the design of the product architecture.
And this paper (pdf) analyzing 29 projects at HP. Quotes: (emphasis is mine)
In the final model predicting defect rate, three development process measures and one control variable (for systems software projects) were significant. Together, these measures explain over 74 percent of the variation in defect rate. The significant development process measures are the use of
- An early prototype
- Design reviews
- Integration or regression testing at check-in
The results illustrate that different software development practices are often associated with different dimensions of performance. For example, the use of integration or regression tests as code is checked in appears in our final model predicting defect rate but not in the model predicting productivity. Conversely, the use of daily builds appears in our final model predicting productivity but not in the model predicting defect rate.
Some practices that are correlated with performance when considered in isolation do not appear as significant predictors in multivariate models. For example, we initially found that having a less complete functional specification when coding begins is associated with lower productivity, lending support to the waterfall model of development. When we accounted for the variance explained by releasing early prototypes and using daily builds, however, this relationship disappeared. (A similar pattern exists for the relationship between a more complete detailed design specification and a lower defect rate.) In a sense, these other practices appear to “make up” for the potential trade-offs arising from an incomplete specification. This suggests that development models should be considered as coherent systems of practices, some of which are required to overcome the potential trade-offs arising from the use (or absence) of others. To the degree that such a process relies on a coherent system of practices, a piecemeal approach is likely to lead to disappointment.
One thing about statistical studies is that they do end up treating people as interchangeable components. Only one of the two studies linked to above mentions the possibility of experience of the developers as a contributer to project success. This is why Alistair Cockburn wrote Characterizing people as non-linear, first-order components in software development. Did these studies measure "good citizenship", "taking initiative", or the effects of dominant personalities?