All too often, software projects are late, over budget, or end up with less functionality than first planned. If these were consumer products, most software development shops would probably find themselves under FTC scrutiny.
Despite the high-tech veneer, software development practices probably have more in common with 17th century English blacksmith shops. Forget the fancy tools, most software is still crafted by hand.
Production is closer to black art than science. Credit or blame developer culture. Comprised largely of former (or would-be) chess players, philosophers, and artists (OK, there are engineers and scientists too), the field has always valued creativity. Not surprisingly, when you get this kind of mix of people and priorities together, the results are often breakthrough, chaos, or something in between. Call that a mismatch with the intended market, because development of business software requires creativity tempered with discipline and consistency.
Not surprisingly, attempts to industrialize software development have typically fallen short. Approaches, ranging from CASE (Computer-Assisted Software Engineering) to Extreme Programming (XP) have been plagued by over reliance on pure top-down or bottom-up emphases.
For instance, component-based development (a form of CASE “lite”) aimed to streamline the process with development of modular software that could be reused. This approach fell apart for several reasons: components were too complex to build, developers and business analysts alike had difficulties forecasting future needs, while developers viewed reuse as attacks on their manhoods because it stifled creativity. Not surprisingly, when we studied Java development practices several years back, we found most developers dispensing with Enterprise Java Bean (EJB) components in favor of simpler, modular, but less reusable Java servlets.
In industry sectors with processes common enough to provide sufficiently broad markets for software vendors, packages replaced internal development. However, when a company buys a package, it becomes hostage to the marketing priorities and fortunes of its software vendor. (How would you feel if you were a PeopleSoft customer today?)
In markets too narrow for package providers, other approaches have emerged. For instance, we’ve recently heard about the notion of co-sourcing, where multiple companies in a sector cooperate on development of commodity software, such as for regulatory compliance.
And a few days ago, we caught an announcement from Unisys of a new “Business Blueprints” strategy that could provide yet another alternative. The blueprints are, in effect, general frameworks for business processes in sectors untouched by package vendors. Essentially a controlled development solution, Unisys boasts an efficient software development process that saves time and money through strict adoption of the Rational Unified Process (RUP) for ensuring that software code is driven by requirements, gets thorough testing, and is carefully controlled for changes that could blow the scope of a project.
While vendors always bend over backwards to make reference customers successful, we were impressed with Unisys’ successes at ING Barings, where it developed the first phase of an insurance policy management system. Using cost estimation tools, the Unisys team predicted costs of this multi-million dollar project within a few percentage points, using that uncanny accuracy to prevent scope creep.
It could be argued that such results are only possible through heroic measures. But, during a period when offshore development is competing for programmer’s livelihoods, maybe a little heroism wouldn’t hurt.