36.2. Getting Fit at RPS The RPS programmers had originally voiced several major concerns with the architecture, Fit tests, and the development of RentEz. Let's review progress on their concerns, and see what Emily, Neo, and the other programmers report now. We're concerned about the changes we will have to make to the system for testing. It's already difficult to change the system without breaking it, as it's so delicate. "It was slow to get the Fit tests in place and then to get them working quickly. As we've test infected the system, it's delicate only in some parts. Everyone is more at ease about refactoring to improve it. It's weird to think that we were so fearful of making changes to it." This means that we're often slower to add new functionality than we, and everyone else, expect. "This is still so for changes that involve the disorganized parts. But changes in the refactored parts often go faster than expected. Having the automated tests for fast feedback means that any code we break during a change doesn't stay broken for long." We know that the architecture needs rethinking. There's lots of duplicate code, and we need to change the structure of some of the classes. In some places, there's lots of conditional code that could be eliminated by introducing several subclasses. But it's very risky to change it, as it's easy to break working code in the process. "We're starting to be proud of the code again. As we make changes, supported by tests, we remove redundancy. We sometimes find now that adding functionality leads to code shrinkage, as we're able to introduce useful abstractions." We've got a backlog of work to be done, including many reported bugs, so management will not support long delays while we improve the system. "The backlog remains as we make progress on the changes. I imagine that it won't be long before we're going faster and can reduce the backlog. The number of reported bugs is way down on the last release, which is brilliant." But turning it into a Web application is going to force a lot of changes, so we need to tackle it somehow. "That's going surprisingly well. We were not looking forward to doing that. Now it drops out of the process of separating the presentation and domain layers. This has raised some new ideas about the best way of presenting information in both the GUI and the Web interface." Some of the code was written by people who have since left, and we're not familiar with it. We're bothered about changing such code, as we often introduce bugs in the process. Some of it is very stable, whereas other parts probably need to be replaced entirely. "Where we've had to deal with such code, owing to bugs or new developments, pair programming has eased some of the pain. In some cases, we've discarded code and redeveloped it test first. Often, it's quicker to do that than to try and understand and fix what's there. We expect this to be a nonproblem in future, as we no longer have code ownership." Our users keep changing their minds about what they require, which can waste a lot of time. "We realize that some change is inevitable. The small iterations to give quick feedback to the customers seems to really help here. The feedback we get now is much more useful, too." And sometimes we add functionality that ends up not being used. "At least we don't spend so long on it before it gets scrapped." It's a pain having to work overtime to avoid running too much over our deadlines for a release, especially as the code tends to be buggier than usual. "The iterations have helped here, too. Others now understand about the effort it takes, and our estimates have gotten better. There is less pressure for releases. However, we find that pair programming is tiring; it's hard to slack off with someone there, keeping you to task." Morale is lower than it's ever been. We used to be proud of the system, but not anymore. "Morale is improving all the time. We all enjoy our work so much more. Two programmers talked of leaving but now seem quite settled. It would have been a shame to lose them, as they really contribute to the team."
|
