Dec 10 2007
Will Your Software Work in the Year 10000?
Your correspondent was once chastised by his developers for the following T-SQL line in a stored procedure:
declare @sYear varchar(5) — y10k support
(For various reasons not relevant to this discussion the year had to be stored as a string.)
You might think only four characters are needed to store a year value. But you correspondent didn’t want the code to fail in the year 10000 – so this code is Y10K compliant.
Is this an example of extreme ego, to think that one’s own code would actually be in use in eight millennia from now? No.
Remember that the whole Y2K problem arose from programmers in the 70s assuming their own software would never be used in 25+ years in the crazy year 2000. The point isn’t that you should assume your software will run for 8,000 years. The lesson here is that it’s important to challenge your own assumptions.
Assumptions are dangerous. They tend to lead to a lack of innovation. Why? Because so much innovation in software happens simply because someone new looks at a solution and says “Why the hell do you do it like that? Why can’t we do it this way?”
The answer is usually “Because we’ve always done it like that.” Often this is a sign of institutionalized stagnation.
When you work on a project you don’t have the luxury of being able to look at the issues at hand with a fresh face. But that doesn’t mean you can’t reap some of the benefits that real fresh perspective offers on a project you manage or develop daily.
The whole point of challenging your assumptions is to tease this fresh perspective out of your own entrenched thinking.
So how do you do this? One easy way is to make it a habit to periodically stop and think as you program: “Wait, can I do this a different way?”
Do this once a day — or even once a week — and you’ll be surprised at the new ideas. Sure, constant revolution tends to result in massive famine and death when applied to entire nation states, but in software continual evolution is a competitive edge and a must.
This explains (partly) why failure is so advantageous to learning. Sure, you learn how to do something when you do it right, but you learn just as much (more?) when you learn how not to do something.
Does a stored procedure really need to support 5-digit years? Probably not. But it does help if you reset your thought pattern every once and awhile, get a fresh perspective and try something new.