« July 2008 | Main | September 2008 »
August 31, 2008
Chinese Olympic Gold Medals
Factoid: in 1984, China didn't win a single Olympic medal.
In the last Olympics in Beijing, they won an incredible 51 gold medals, The next closest was the United States at 36, and Russia at 23.
When I heard that statistic while on vacation last week with my children in Ogunguit Maine, I recalled a statement made by my fellow Cutter Consortium colleague Rob Austin, a professor at Harvard Business School. During a Cutter Summit Conference, Rob mentioned that in a nation of over 1.3 billion people, that China has more honor students than the U.S. has... students.
In my volunteer time, I happen to be a trustee at the Berkshire Country Day School in Lenox MA, a remarkable place that's provided a stellar independent school education here in the Berkshire mountains of western Massachusetts for more than 60 years. This year, we have an enrollment of about 180 students from pre-K through 9th grade. I imagine that in future years - our kids will have to compete against a nation where their A and A+ students outnumber our total students. Yikes.
In another interesting article from this weeks NY Times, another milestone has been reached: data that flows through the Internet now increasingly flows around the United States. In short, the era of Internet dominance by the U.S. is officially over.
Are becoming less relevant in the global economy, or at the threshold of irrelevance? Ed Yourdon, are you listening? Has anyone read some of Richard Florida's recent writings on the creative economy, most notably, "The Flight of the Creative Class"?
What happens when all those Chinese students decide that knocking off DVDs and CDs is boring, and that it's time to get creative and design killer-app software applications and other products and services that come from innovative thinking?
Posted by Mike at 11:20 PM | Comments (0)
August 21, 2008
Jim Highsmith on Intrinsic Quality
I really liked this article by Jim Highsmith who is the Director of Cutter's Agile Product & Project Management Practice, so much so that I thought to post it here.
Much of Jim's writing on topics like these are available via Cutter Consortium. Ask for Jack Wainwright who can set you up with readership passwords and trial evaluations of Cutter's content.
Cheers :) Michael
-----------------------------
Intrinsic Quality: Why Testing Takes Time
This is a continuation of previous Advisors on quality, specifically ones on intrinsic quality (see " Investigating Agile: Inside and Out," 19 June 2008 and " Intrinsic Quality?" 3 July 2008). I want to address a very basic question: why is technical (intrinsic) quality so important? In previous Advisors and in the agile literature, the reduction of technical debt has been widely discussed. Agile pundits pose that continuous, comprehensive (every day, every iteration), automated testing is required to be truly agile. In this article, I'd like to address three very important aspects of why the focus on technical debt and testing are so critical: the impact of code quality on testing time, error location dynamics, and error feedback ratio.
Many people estimate testing time completely incorrectly -- mostly because they don't understand testing. The rough guideline they may use is something like: "Well, it took five days to code it, I guess it will take about three days to test it." While this rough estimate may work at times, testing time in general is not related directly to coding time. Testing time is related to defect density. For example, take a coding effort that takes four developers 10 days and they produce four KLOC (thousand lines of code). Assuming a half day to find and fix a defect, the testing time for a team that produces a module with one defect per KLOC (an achievable level) is two days. Code produced that had 15 defects per KLOC (very possible with a team that does minimal unit testing nor any automated testing) would require 30 days of testing time!
Many development teams, and many managers, wonder why testing takes so long -- and blame the testing team (the coding team made their schedule!). The greatest impact on testing time is not the testing team, however, but the coding team -- and their defect densities. A number of quantitative studies done in recent years by Cutter Senior Consultant Michael Mah attest to the higher quality of many agile projects and the positive impact on scheduling.
A second testing issue is error-location dynamics. A number of years ago, a large computer manufacturer did some studies of the time it took to find errors in software. The curve goes up from one or two hours to find easier defects to more than 50 hours for a small percentage of hard-to-find defects. Years ago, in one major airline reservation system, it took more than six months to find a bug that brought both primary and secondary systems down. One question this raises for testing is: how much money can you spend looking for unfound defects? The answer for a computer game and the space shuttle's avionics software would be much different. The agile practice of refactoring (both code and tests) can significantly decrease the percentage of hard-to-find bugs by improving code design, thereby reducing testing time. There will always be a curve of harder-to-find bugs, but the shape of the curve can be greatly altered by producing quality code.
The final testing factor to explore is error-feedback ratio, which is the number of new defects injected when fixing existing defects (20 new defects generated in fixing 100 defects would be an error-feedback ratio of 20%). Several years ago, Jerry Weinberg conducted studies on error-feedback ratio and found that a 20% difference in feedback ratio leads to an 88% difference in completion time (bad enough), but the next 10% increase leads to a 112% increase.
Have you ever worked on a project in which the code never seemed to stabilize, no matter how much testing was done? If the code has a high defect density to begin with, then it will probably have a high error-feedback ratio as well. Low-quality code causes worse error-location dynamics. Have you ever worked on a project where the testing seemed to take forever -- multiples of the budgeted time? All three of these factors we've discussed show why poor code (high defect density, lengthy error location curves, and high error-feedback rations) can lead to an inordinate amount of testing -- testing that can never (and I mean never, no matter how much testing is done), result in a high-quality code base.
In every maintenance release, the problem gets worse.
Agile developers and testers know that reducing technical debt (increasing intrinsic quality) is important. These three intrinsic quality factors -- the impact of code quality on testing time, error location dynamics, and error feedback ratio -- can help explain technical debt.
I welcome your comments on this Advisor and encourage you to send your insights on agile techniques and practices in general to me at jhighsmith@cutter.com.
Posted by Mike at 4:36 PM | Comments (0)