FRAMINGHAM (07/24/2000) - E-business has changed more than just the way businesses interact with their customers. In some cases, it has also changed the basic principles and assumptions of software engineering processes and methodologies. For example, Barry Boehm first provided us with the insight, in his 1981 textbook, Software Engineering Economics, that if a software engineer made a mistake during a project's systems analysis phase by misstating or overlooking an end-user requirement, it was 10 times cheaper to identify the problem while the project was still in that phase than to allow it to go undetected until design. If that same error remained undetected until the coding phase, it would be 100 times more expensive to fix than if it had been found when it first occurred.
But there's a fundamental assumption built into this maxim that today's e-business projects are forcing us to confront: Boehm's order-of-magnitude escalation figures are relevant only if it's somehow possible to identify the defect during the phase when it occurs. Throughout the 1990s, we often justified prototyping and rapid application development methodologies on the theory that end users were too busy or distracted to make the effort to carefully document their requirements with dataflow diagrams or Unified Modeling Language models. But Boehm still haunted us, because we thought that maybe we could have worked harder to articulate user requirements before the first prototype was built.
In today's e-business environment, even the most ardent supporter of formal software engineering methodologies has to admit that we're operating in uncharted territory. Not only are today's projects taking place at breakneck speed, a.k.a. "Internet time," but the business environment is so chaotic that it's almost impossible for executives to even define the strategy and tactics associated with the development of a new system. When Jeff Bezos envisioned the requirements for Amazon.com Inc., how could he possibly have known what his needs were, in sufficient detail, to avoid some defects that would eventually become known during coding and testing? Amazon was the start of a new world.
Similarly, formal software engineering advocates argue that if a defect is found during systems development, it shouldn't be blamed on the individual who committed the defect. Instead, it should lead to a re-examination of the process that allowed the defect to occur. One of the more popular approaches is causal defect analysis. Throughout the 1980s and '90s, it gained great favor in the most advanced IT development organizations and was credited with achieving dramatic improvements in software quality and productivity - sometimes as much as a fivefold increase in productivity and a tenfold reduction in defects.
But again, the causal defect approach is based on a fundamental assumption that isn't always appropriate in today's e-business environment. The only reason it's worth investing the time and energy to identify the flaw in a software development process is because we intend to use the same process again; our next project is going to be similar enough to the last project that it makes sense to use the same process. But we're now going through a period of disruptive technology; there's no assurance that project N+1 will have any similarity to project N. As a result, yesterday's process might have to be changed substantially for tomorrow. In turn, it might not be worth the effort to fix anything other than major flaws in the process, on the assumption that the details are going to be useful only for a single project.
Obviously, there are circumstances where neither of these two scenarios is valid. Thus, there are circumstances where we can continue to depend on the old, fundamental principles and guidelines of software engineering. But it behooves us to remember what assumptions lie behind those principles, and to ask ourselves whether the assumptions are still valid. E-business really does represent a mind shift, and it's going to change the world of project managers, methodology developers and process purists just as much as that of business executives and customers.
Yourdon is editor of Cutter IT Journal, published by Cutter Consortium in Arlington, Mass. Contact him at www.yourdon.com.