Bite the bullet - IT executives can use year 2000 compliance efforts for software development efforts - Industry Trend or Event

Software Magazine, Oct 15, 1997 by Axel Kehlenbeck

IT executives have long been looking for a "silver bullet" that will automate their software development processes and improve their ability to deliver quality products on time. This search has led many organizations to blindly adopt new software development technology, including RAD, object-oriented development tools, components, and Java. These silver bullet wannabes have provided some improvements, yet they have not enabled development organizations to achieve their goals.

But, while there's no silver bullet, there is a silver lining. Surprisingly, it comes as a result of Year 2000 compliance efforts. As development organizations try to make their applications Year 2000-ready, they're adopting industry-defined development and test processes, as well as automated development tools. Those that adopt such remediation processes for their Y2K efforts will find the real answer to their development problems lies in the process and its automation. They'll see that software development is really an engineering discipline, not an art form.

For too long, software developers have been considered "artists" because, at least in undisciplined organizations, they often don't have the time to leave a trail documenting what goes into their efforts. They are called upon to quickly deliver programs to serve departmental and business needs, and may feel they don't have the luxury of adhering to defined steps to get the job done. Also contributing to the artist tag is the fact that many in upper management don't have a clue as to what goes into developing software. The reality, however, is that software development should be approached just like any other engineering pursuit. After all, software engineers receive training similar to other engineers, and must understand specific core technologies, programming techniques, and computer structures and architectures if they're going to write any software program.

But there's hope for development teams. What we forget is that engineers in all industries -- from automotive to telecommunications -- have encountered the same problems as today's software engineers. Products were late and unreliable, lacked the required functionality, and didn't work when they were integrated. The only difference is that other industries solved most of their problems years ago.

For instance, in the late '70s and early '80s, the electronic hardware industry was building new, complex products that were late to market, didn't meet performance expectations, and failed quickly in the field. Engineers had multiple tools and solutions at their disposal for automating segments of the development process, but none that would automate the entire process. Engineers had to redo pieces of their work to move from one stage or process to the next, and complementary tools such as electronic design, simulation, schematic capture, and manufacturing systems didn't talk to each other.

Engineers tried different solutions to integrate their tools. One such solution -- EDI -- still exists today and is regarded as the cornerstone of supply-chain management. Formerly known as EDIF or Electronic Data Interchange Format, EDI enables tools to communicate through electronic data exchange. Still, EDI was only a partial solution. Not until the industry combined standard development methodologies with automated, integrated tools were development goals achieved. Today, the hardware industry is capable of delivering products on time with the targeted functionality and quality.

Meanwhile, the automotive industry, using the same development processes as the hardware industry, has cut new vehicle development time by more than half -- from six or seven years to less than three. This efficiency has ensured the survival of the U.S. auto industry by enabling it to remain competitive with overseas manufacturers.

No IT organization will be able to make all of its applications Year 2000-compliant and deploy them before January 1, 2000 without following at least some of the practices described throughout this issue of Software Magazine. These practices, supported by automated con- figuration management, analysis and design, code remediation, and test tools, will help companies reach their Year 2000 conversion goals.

For the longer term, companies that continue to follow structured development processes -- such as those defined by ISO 9000, the Software Engineering Institute's CMM, ASQC, and others -- will gain competitive advantage.