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.
Overall, more than three-fourths of the seminar participants chose “Managing expectations” (rather than differing goals or terminology) as their biggest barrier to communication within their project teams.
Its probably going to be a good synergy, therefore, that Borland last week acquired Starbase in what I see as a good cultural fit and a strong complementary relationship between product lines. Borlands JBuilder, for example, blazed the trail later followed by Microsofts Visual Studio .Net in transforming integrated development environments into Web-oriented portals; the Starbase Web-based configuration management systems should integrate smoothly into that framework. Ill probably have more to say about this when I return from this weeks Starbase user conference in San Diego.
Another appealing approach to development team support comes from SpeeDev Inc., whose SpeeDev Suite integrates requirements management, development issue resolution and nitty-gritty issues such as billing of developers time to clients and tasks. Ive had the benefit of a thorough walk-through with the companys engineers, and found this suite especially impressive in connecting development tasks back to underlying requirements. Many project managers who already use Microsoft Project will appreciate the two-way integration between the SpeeDev and Microsoft products, with adjustments to tasks in either environment being reflected in the other.
As a discipline, software development has a remarkably poor success rate. Part of that statistic is actually a positive indication that a software solution is cheap to try, and discard if it doesnt work out. Overall, though, I think we can agree that well have to do better–at both the old tasks of communicating with each other and at the new tasks of communicating with next-generation hardware–so that we dont merely do more things at once, but also do the right things.