Projects and Parallelism: Keeping Hardware, and People, Productive
Peter Coffee: As processor architectures invite more powerful parallel techniques for peak efficiency, long-standing management problems call for better collaboration tools.What does the "Tickle-Me Elmo" animated doll have in common with the Boeing 777 airliner? Both are cited as examples of softwares growing role, not as just an automation tool for back-office functions, but as the technology that either defines a product or creates a crucial competitive advantage. Your own strategic enterprise application may have neither red fur nor wings, but its still both a potential attention-getter or a potential crash-and-burn scenario. Unfortunately, as I head for San Jose to attend this weeks Microprocessor Forum, Im reminded of a comment at a past Forum session to the effect that software--rather than hardware--has ironically come to be the "hard" part of IT. At this point, a Forum presenter observed a few years ago, its easy for chip makers to deliver far more parallel-processing potential than programmers know how to use--with the result that most of the effort in developing a new microprocessor goes into finding ways to identify parallelism, either at compile time or at run time, that application developers dont generally have the training theyd need to seek or express at design time. AMDs Athlon architecture concentrates on run-time opportunities; the compile-time approach is where Intel is placing its bets with the Itanium, but there are intellectual-property issues as well as intrinsic difficulty issues that make this more than one kind of risk.
More than the limits of development technologies, though, what slows the pace of software development seems to be primarily the challenges found in "problem space" rather than "solution space"--that is, the difficulties of agreeing on what to do, rather than getting it done. When I moderated Starbase Corp.s Aug. 22 eSeminar, "Aligning IT with Business," I asked more than 300 virtual attendees where they felt their development teams most needed to spend more time: Seven-eighths of their answers were in planning, analysis and design, compared with only 4 percent feeling that additional time was most needed in development and 9 percent in testing.