Refactoring Ytwok

I'd like to convince you that the Y2K debacle is not the result of applying YouArentGonnaNeedIt, but that it is instead the result of many years of programming practices which we now all know to be inferior.

Imagine if you will, a past in which object-orientation and reuse had become the way we developed software, rather than the chaotic not-invented-here hackery that was the best we were able to create back then. (And I was there back then, and we were doing our best.)

In this alternate history, the object library (there is of course only one) contains a Date object which happens to support only 2-digit years. (Even if our practices were perfect, somehow we came up with this 2-digit date thing.)

Our input/output formats are all in the library also, and of course all the date ones are part of the date class. Record-level I/O formats are collections of formats for various objects, recursively down until you find the Date formats (which probably recursively use Integer and String formats).

Of course your own programs use these objects, and equally of course all your commercial software, databases and so on, also use these same objects. Industry-wide reuse. BradCox is President of the World, did I mention that?

One day someone notices, amid all this glory, that the year 2000 is coming, and the response to this discovery is that we need to do something about the 2-digit year thing.

We go to the Date class, and enhance it to 4-digit date computation. We change the IO formats to read and write 4-digit dates.

We run our tests. All the programs that use dates internally, or that create new files and subsequently read them, work. They have all inherited the new Date class and the new Date I/O. But the programs that read old files don't work: the old files have two-digit dates in them.

We modify the Date I/O routines to accept the old 2-digit input format and the new 4-digit format. We run the tests again. Now all the tests run. We release the new Date class to the library and go home early.

From this slightly(!) idealized story we can now see that the Y2K problem was caused by poor factoring and lack of reuse, not by application of YouArentGonnaNeedIt. --RonJeffries

The entire idea of factoring is justified by the thought of the cost of change. Without thinking about Y2K it wouldn't occur to someone that the factoring was poor. Only in hindsight do we see that another factoring would have been better. --AlistairCockburn

On the contrary, OnceAndOnlyOnce is sufficient to cause you to encapsulate all date logic into a Date class (if you have classes). You don't have to have fore- or hindsight to do this, it's part of DoTheSimplestThingThatCouldPossiblyWork. We always keep the code clean, because that keeps the cost of every change down, whether that's the next foreseen change or the next unforeseen one.--RonJeffries

See Also: YtwokSecondaryEffects

To me, OnceAndOnlyOnce is an example of OneKnob?. When we choose the classes for a system we are choosing the knobs that can be used to adjust its behavior. Date is a very evident knob. If all the logic for dates is in OneKnob?, backward compatible change is easy. If you have twelve date classes and representations that need to talk to each other, you don't even have twelve knobs for date, you have none.

I think that AspectOrientedProgramming tries to make knobs of things that are not normally seen in code. I also think that refactoring is making finer knobs out of coarser knobs and introducing new knobs. Some systems don't have a knob for date, simply because nobody ever thought date should be a knob. I think that the profound thing is that in object oriented programming, we pick our coarse knobs when we pick our metaphors. The WholeSortOfGeneralMishMash can be sliced many ways.

-- MichaelFeathers

Actually, the Y2K problem was caused by YAGNI with poor factoring. Only apply YAGNI if you RefactorMercilessly!

CategoryYtwok