Initial History of Change


In 1999, before the release of Kent Beck's book on Extreme Programming, several projects were undertaken to try to address the problems. They are relevant because it is in the context of these projects that Extreme Programming was introduced and began to take hold. In this context we saw that many of the things we were already doing were elements of Extreme Programming.

Refactoring

A second refactoring effort was started late in 1999. This project focused on implementing continuous change and is ongoing today. The initial focus was around resolving problems reported by many customers that related to poorly implemented modules. Bug clusters highlighted in our defect tracking system clearly identified these problem areas.

This refactoring project continues as part of our Extreme Programming effort, as part of every engineer's response to problem resolution. An additional outcome was to reduce the complexity of the code by stripping out unused code and implementing several patterns that have made it easier to maintain, test, and understand the code. Code size has been reduced by over 40%.

Improving Engineering Practices

The refactoring project was led by one of IONA's distinguished engineers, who, in addition to providing strong technical insight into the problems in the code, was also instrumental in helping promote stronger engineering practices. He initiated several practices to encourage growth in the engineering team, including such things as weekly presentations to give not only himself but others in the engineering group an opportunity to present technical topics of relevance or interest, such as merge strategies, patterns, and estimation. He drove code reviews, advocated adherence to source code management guidelines, and focused people on ownership and responsibility for code style. He made engineers think of how they could constantly improve the quality of their work in areas such as test coverage, and in general established a more proactive approach to problem solving. His practices continue to strongly influence the team.

Automating Everything

A project was established to clearly understand all the build and test dependencies across all the elements of the older product set and to fully automate the entire build and test process. This project is ongoing but has resulted in the ability to build and unit test the complete product set nightly. Efforts continue to improve the automation of the interoperability and system tests that still need some manual intervention.

Team Consolidation

We should make a final comment on the team and the state of affairs just before our initial experiments with Extreme Programming. Before starting the projects described earlier, over 70 engineers maintained and enhanced the Orbix products. By the time we completed the major portion of those projects, we had been able to reduce the team to around 40. We continued to see the same trends in the number of issues coming into the Generation 3 team that we had always seen, but we were servicing three times the number of customers. Besides consolidating personnel, the team managed a single mainline of code using a well-defined set of common rules of the road, which govern the merging of fixes and enhancements into the consolidated mainline.

This was a remarkable transformation. We had started down the road toward a consistent, automated build, test, and release infrastructure that would enable complete product build and test every night. The refactoring efforts were eliminating much of the code complexity and stagnant code and had resulted in a clean, well-structured code base that conformed to IONA code standards.

So if we were seeing all this improvement, why look at Extreme Programming? It's all about constant improvement. We hadn't resolved the issues around testing, visibility, morale, and fundamentally personal work practices. We wanted to continue to do better. From a management standpoint, we wanted to be able to do more with less. Higher productivity, coupled with increased quality, leads to decreased team size with improving customer satisfaction. The engineers wanted more time to do good work, as opposed to always feeling under pressure to deliver fix after fix.

Even with the projects we had put in place, we still weren't where we felt we should be. This came from both management and the team. Many engineers and managers had started to look at Extreme Programming, and guess what? Many of the elements of Extreme Programming come naturally to teams working the maintenance game. We didn't know it, but we were already doing a lot of Extreme things. Extreme Programming validated some of the ideas that had initiated the previously described projects refactoring, testing, and test automation in particular. It also suggested some approaches that could help us resolve the issues that were still outstanding: increased productivity, visibility, team morale, and improved testing. Extreme Programming started to make some sense.



Extreme Programming Perspectives
Extreme Programming Perspectives
ISBN: 0201770059
EAN: 2147483647
Year: 2005
Pages: 445

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net