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 they were too process-oriented and not focused enough on the creative side of software development. Also, many of these software shops were affected by a trend that hits close to home: offshore outsourcing. “What happened to the Japanese software factories? They went to India,” Cusumano said.
Imagination and innovation are keys in this process. Cusumano recommended that software design and development be “slightly out of control,” but also have a fundamental arrangement underlying operations. “You can’t do anything complex unless you have structure,” he said. “For creative people, this structure should be as subtle as possible.” Thus, organizations should cater to people with creative minds who might also have idiosyncratic personalities, yet maintain boundaries. Cusumano included a relevant quote on the subject from Dave Maritz, who served as the test manager for Windows 95. “Who cares if a guy walks around without shoes all day?” Maritz said. “I don’t care…(but if) somebody hasn’t checked in his code by five o’clock, then that guy knows I’m going to get into his office.”
But creativity can be taken overboard as well. Cusumano pointed to Netscape, which constantly rolled out and promoted new features for its products (at the expense of time and quality) and wound up with line after line of convoluted “spaghetti” code. Initially, this iterative, semi-chaotic approach might thrive, but over time, you have to find a balance between efficiency and innovation. The road to long-term success begins with a solid architecture that can be evolved incrementally, Cusumano explained. “The most important feature is the foundation. You can’t build features on top of nothing. You have to build on an infrastructure.”
This strategy involved providing good functionality early on, then adding robust features as needs arise. With all these additional elements, overall balance and maintenance of the product have to be considered. “Part of it is to anticipate those kinds of changes in your architecture,” Cusumano said. “If the change blindsides you, then you just have to do rework.”
Perhaps the most important point of all, though, is to remember why you’re working in the first place: to ship new and high-quality products. Software development is a business, and should be viewed as such. This is one of the main reasons U.S. firms have been so successful in this sphere. They had the right perspective from the outset. European and Japanese software companies have viewed the field more as a science, and have focused on ultimately meaningless statistics (at least from a commercial standpoint) like the amount of lines of code produced. Thus, they have lagged behind in many respects—not because they didn’t know the subject matter or didn’t work hard—but because they lacked a practical, profit-driven mindset. So the main take-away here is when it comes to software, keep your eye on the bottom line.