Xp Challenge Ytwok

Formerly ExtremeProgrammingChallengeEight

Y2K - the big zero. A Japanese bank has just realized the enormity of the task before it. Their in-house y2k consultants have committed seppuku. You're offered a totally outrageous sum to fix/replace this bank's ~250 million lines of code before Japanese fiscal y2k - 4/1/99 - just a few months from now.

You know failure is almost certain, but maybe you can do some good for them while making enough in gold bullion to set you up for life. You're willing to give it a try. Can XP make a difference?

What will make a difference is the business version of WorstThingsFirst, aka ExtremePlanning. That will tell you which systems to implement first. If the bank has a big retail component and a few commercial loans, we'd implement retail first and let commercial crash and burn (if necessary and if it would save the company). I would suggest that everything possible be implemented with standard packages with whatever changes are necessary to the business to make this easy. But first I would quickly experiment to see if that was really easier or if a minimal custom system would be better.

For marginal or low volume pieces of the business, I would re-introduce manual practices (DoTheSimplestThingThatCouldPossiblyWork). I was astounded to discover how much of bank "processing" is manual even today. --KentBeck

I reflected on this a little and particularly like the last part. Y2K projects really ought to start with reintroduction of manual practices. Then introduce the SimplestThingThatCouldPossiblyWork to automate each of these. Then, if you have time left, start to integrate - but always with fallback to your simple automation, and then with fallback to manual practice. A bit like the way StarTrekSystems fail - gracefully, even when some components go up in smoke. This way your business can continue to some extent even if the YtwokEmbeddedSystems problems really bite.

PeterMerel

My brother has a small practice-- 5 doctors, 15 employees. And they had a billing system from the early 1980s. He paid a service fee every year and the people that sold the system maintained it.

Last year, they said "Y2K. We need to rewrite the (presumably custom) software we installed way back when. It'll cost approx $50k." He blanched and called me asking what to do.

I told him to use the money to buy a new PC-based network with a modern accounting package. And then, as customers come in, enter the salient parts of their accounts into the new system (of course, new accounts are only entered into the new system).

It's a bit inelegant (manually re-entering a lot of information) but the time-cost is amortized and he gets both a much more modern computing system and a Y2k solution in the deal. The only assumption he needed to make was that any customer who hadn't been back in 2 years (and owed him money) wasn't going to be back (e.g. that records not transferred during this process aren't important to the business).

I remember this well because he was expecting me to mention some magical piece of software to handle the Y2k issue. And, instead, I gave him a solution he could understand.

-- WilliamGrosso

Well done! -- PeterMerel

But now I wonder whether there's also an XP approach to the embedded systems remediation? -- PeterMerel

Why not do AcceptanceTests on the bank's systems first? Maybe they will work.

I just finished a Y2K compliance effort on a new system. First, a lot of effort went into CodeScanning? to find potential Y2K traps. Then a lot of effort went into planning how to address the Y2K issues found by the CodeScanning?. Then an AcceptanceTestPlan was developed, focusing on UserStories happening in and around 2000. Then the system was tested. The only bugs found were in ThirdPartySoftware? (a JDBC driver). A quick update of the driver, retest, and everything worked great.

All the effort of CodeScanning? and development plans to address the CodeScanning? results were a waste of money. TestFirst. That seems extreme.

-- HankRoark

But of course! The best XPers always write the test first and then run it. Sometimes you luck out!

I've been wondering about this in XP also. Maybe the first step is write an ApplicationFacade? and some AcceptanceTests. Test. Does it work? No. Do some carding write some UnitTests, some code, and see the acceptance tests come to life. -- MichaelFeathers