Wednesday, May 19, 2004Zane's been wrestling with quality control
in light of expanding projects. He makes the assertion that
"investing in quality" in both developer and support staff hires, as
well as in software construction decisions can make the number of
man-hours less linear. In other words, proportionate support
levels will drop off as the project grows as long as it grows in an
appropriate manner. The idea has been bouncing back and forth
between Zane and Cote's blog.
Before I dive into the issue itself, let me say that this is what I
love about weblogs. These civil, and enlightening back and forths
are so much better than the one-sided issue debates you get in a closed
process.
Since I'm no longer doing software development, I have little to add to this discussion in terms of empirical evidence. However, at the risk of appearing like an idiot let me throw a wrinkle in the discussion that may not have been thought of. The idea that you can make the correct decisions time and again by hiring the correct staff may be a little off-base. Let's look at it through the filter of cumulative probabilities.
Let's say you have to make 50 design decisions in a year that are critical (i.e. where making an incorrect decision will cost time and money and drag down productivity). Let's also say that on average a good designer/programmer/tester what have you has a 95% success rate (meaning that they choose the right choice 95% of the time, and one of the wrong choices 5% of the time). What this means is that in a given year making those 50 decisions you have a 92.3% chance of introducing a productivity drain into the system. I think this is instructive since you only have to make one or two bad design decisions to really cause problems.
You extrapolate this across multiple personnel maintaining a decent sized project and you can see how this would make even an extraordinary staff working on extraordinary code eventually drift towards mediocrity.
4:11:46 PM #
Since I'm no longer doing software development, I have little to add to this discussion in terms of empirical evidence. However, at the risk of appearing like an idiot let me throw a wrinkle in the discussion that may not have been thought of. The idea that you can make the correct decisions time and again by hiring the correct staff may be a little off-base. Let's look at it through the filter of cumulative probabilities.
Let's say you have to make 50 design decisions in a year that are critical (i.e. where making an incorrect decision will cost time and money and drag down productivity). Let's also say that on average a good designer/programmer/tester what have you has a 95% success rate (meaning that they choose the right choice 95% of the time, and one of the wrong choices 5% of the time). What this means is that in a given year making those 50 decisions you have a 92.3% chance of introducing a productivity drain into the system. I think this is instructive since you only have to make one or two bad design decisions to really cause problems.
You extrapolate this across multiple personnel maintaining a decent sized project and you can see how this would make even an extraordinary staff working on extraordinary code eventually drift towards mediocrity.
4:11:46 PM #
No, seriously, MTV is good for our kids. Really. I'm serious. I wouldn't be sarcastic or anything.
2:19:50 PM #
2:19:50 PM #
Copyright 2004 Edward Goodwin
Theme Design by Bryan Bell
