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