The Problems

We focus on four areas in looking at the problems that were identified. Again, these problems are all related to how IONA moved from a start-up to a market-leading provider of middleware products.

Processes and Practices

In early 1999, you could have asked two different engineers from the same Orbix team how they did their job, and they both would have given you a different answer a reflection of the lack of process documentation and visibility as well as a lack of emphasis on making process part of an engineer's personal software practices. Also, there was no focus on process improvement, because the junior engineers assigned to work on maintenance and enhancement had no experience with good engineering practices and had only a rudimentary understanding of process. To compound the problems, the maintenance and enhancement team used disparate source control elements across two globally distributed development sites, and a well-defined and tested interface between configuration units was nonexistent. Dependency management was a nightmare.

Testing

In general, quality for the Orbix product was never one of its high points. Test coverage was not well documented, so good metrics were not available. Test suites were cumbersome, difficult to run, and impossible to report on accurately. Product releases were difficult to system test because the test suite used to provide interoperability testing with other IONA products and product components, or against other CORBA middleware products, was not automated across the platform set that we delivered our product to. Responsibility for quality, instead of lying with the development and maintenance teams, was focused in a quality team that sat outside the engineering effort and monitored quality through quality checklists and forms.

Code Entropy

By the end of 1997, the Orbix code had already been patched and repatched hundreds of times to address large numbers of customer issues as well as the changing CORBA specification. The patching reflected many instances of Band-Aid approaches to resolving problems or adding functionality and was a major factor in the rapid entropy of the code. Many of these unreviewed changes were made to a code base that was never designed to withstand the punishment meted out by many of IONA's larger customer deployment environments. Customers were screaming for fixes and faster resolution times. The degradation of the code was further accelerated by the fact that more and more of the senior development staff were moved off the maintenance team to focus on new products development. Finally, there was limited acceptance of the well-documented style guides that were specified by IONA's chief architect for all code development, making it very difficult to read the code. Poor structuring of the source code's directory space also made it difficult to quickly become familiar with the overall code structure.

Team Morale

The morale of the people working on the maintenance and enhancement team was very low. Several review comments indicated that people didn't feel that there was cohesiveness in the team. Many reported that visibility of all the efforts that people were working on was poor. In general, they felt underappreciated and overworked.

So, these were the major problems facing the team as it started 1999. An initial refactoring project that had run from 1997 to 1999 was finishing up, and although it focused a tremendous amount of resources on refactoring, improving testing, and making necessary changes to the code base to comply with the latest version of the CORBA specification, it still had failed to address most of the issues identified earlier in this chapter. Essentially, it skimmed the surface of what needed to be done.