At a recent conference held by the IT Metrics and Productivity organization, one of the more notable presentations was on the topic of software development approaches, which was conducted by Michael A. Cusumano, professor at the Massachusetts Institute of Technology’s Sloan School of Management and author of the recently released book “The Business of Software.” In this seminar, Cusumano discussed an assortment of strategies from IT’s history, and the lessons they held for the industry.
According to a report released in 1969 by NATO (yup, that NATO), some of the key documented problems in software engineering at the time included communication, productivity, metrics, reliability, hardware dependencies, reuse and maintenance costs. Sound familiar? Many of the people working in software shops today probably encounter some—if not all—of these obstacles in the work they do. “You might come to the conclusion that no progress has been made (in solving problems) in the past 40 years,” Cusumano said. “I don’t think that’s true.”
Indisputably, software has come a long way, baby. But have the actual processes and productivity involved with development similarly improved? Cusumano thinks it has, in some instances. He cited the Japanese software factories of the 1970s and 1980s, which were characterized by established teams and conventional proven processes, as examples of progress. They were extremely efficient and produced software of the highest quality in terms of lines of code versus bugs. So why isn’t the best software coming from Japan nowadays? Well, part of the problem is that…
Please log in or subscribe to read this article