Extreme Programming Challenge Seventeen

For years your product has been promoted by accepting any change or enhancement suggested by a new potential customer if it is theoretically possible and will win a sale.

You have approx. 1,500,000 lines of C/C++, all heavily coupled, with much duplication: as many as six classes/structs representing similar or identical abstractions.

Many parts of the product use sophisticated numerical techniques: SimulatedAnnealing, ComputationalGeometry?, some others.

There is an extensive X-based GUI, but ModelViewController/DocumentView etc. have not been applied.

All the tools data is held in ascii files with highly non-normalised formats: lots more duplication within and between files.

There is high churn. One or two people remain in the company who understood how the product worked a couple of versions ago.

This practice of accepting any and all enhancements has ensured that the product is market leader, and has been for some time. Naturally, management wish to preserve this "responsiveness" for as many more years as it has already been.

Known, serious, defects persist unremedied for years. Changes to the code-base are becoming more expensive exponentially. Startups are beggining to appear with more robust, cheaper competing products, stealing market share.

Management are extremely reluctant to allow any diversion of effort from production (as they see it: adding features) to maintenance (which they would consuder refactoring to be), the two activities are managed separately.

How could XP help you stay "successful"?

We are not successful at this point, since management won't even let us refactor. We're dead, IMO. --rj

Any of the XP techniques could be useful in this situation. The question is how they might be applied.

In the history of the project on which this challenge is based, it is interesting to note that a "troubleshooter", with an excellent track record was brought in as development manager. He attempted to bring in some XP-like practices, and was very popular with the developers, and improved the situation somewhat. He was less popular with management and was eventually given a GoldenHandshake?.

This is a contradictory situation. A system like this is hard to change, and so it will not have every feature that sales would like.

It will have something like every feature sales would like (even if they doesn't work too well), or a contractual obligation outstanding to add such in the near future. The statement is that enhancements are accepted, not delivered.

The situation is contradictory. Contradictory, but (more-or-less) real. Or, it was real some years ago.

It is also of only historical interest to the poster of the challenge.

There are bad situations. Perhaps this was one. XP is mostly about not getting into them. However, if I had to be there (and I wouldn't have to) I'd try the things I listed above. It's important to remember that there are more programming jobs than there are [good] programmers. --RonJeffries

Most of the developers working on that product have since voted with their feet, the product is not long for this world.

Another approach, worth trying before walking, is to sell the primary XP values to management before looking at the best way you're going to achieve them. The ExtremeValues are motherhood statements, almost impossible to argue against. Since they're non-technical, they can communicate to management. Communicate them.

Then, and only then, push on the business process from XP. Try something like the "Requirements and Scheduling Guidelines" in the ExtremeUnifiedProcess. SoftlySoftlyCatcheeMonkey. OnlySayThingsThatCanBeHeard. Only when you have business clamoring for the ExtremeValues can you begin to effect an XP process.

There will be holdouts on the business side. If you really want to make your development become successful, you need to find ways to employ them. Don't work directly, but subtly. Use WuWei. If you're rational, and you use your heads, you can make good use of people who are not and who don't.

Or should this move to XPC16? --PeterMerel

There are a lot of issues here. Some are about how to change your processes and change the way you relate to management. But there is also the issue of how you change your code. If I had 500,000 lines of poorly written, but working, Smalltalk code, I'd refactor it. I'd write tests first, of course. I think I can refactor my way out of any Smalltalk program. But Smalltalk is easier to refactor than C/C++, mostly because of the tools, but also because the language is simpler. It is a lot easier to imagine C programs that are hopeless. In those cases, it is easier to start over from scratch.

Figure out how long it is taking to add features the way things are going. If you started over from scratch, how long would it take you to get to the place where you are now, and how long would it take to add features then? Note that the new system would probably take half the lines of code as the current system. If the current system is as bad as you claim, the point where it is cheaper to redevelop shouldn't be too far in the future.

Sometimes you have to keep adding features to the current system. Then you have two teams, one developing the new system, and one the old system. -RalphJohnson

See ExtremeProgrammingChallenge