How extensible should code actually be?

If you really want a long lasting program, shoot for making sure that your dates can handle past 2038 (that's the next "Y2K").

Dates aside, how does one exactly code for one year from now as opposed to ten years from now? You either write maintainable code or you don't; you can't exactly specify how long until your change "expires".

I suppose one could argue that the next standard of their language will deprecate method Foo, but if a method is going to be deprecated, that's really more a thing of code quality and maintainability than it is coding for future dates.

You should code to the specifications, nothing more, nothing less. If the specifications make provisions for 30 years, you code for 30 years. If the specification gives provisions for 3 months, the same applies.

Just remember though, you also should code for your own sanity. All the code you create should achieve 3 things:

• Code to be replaceable - This is just good practice in my opinion. The more replaceable you are in your coding, the better code you produce. This provides a bit of a reverse situation - the more replaceable you make your code, the more valuable you make yourself.

• Code to be productive - Reuse, reuse, reuse.

• Code should be well-written - This does not need explaining.

One of the hard piece of judgement to achieve is how extensible to be. As the boss, I am really irritated when I assign someone a 2 hour task and three days later they're still working on it, because they decided it should be more extensible so they added entries to the config file and columns to tables and had to change 4 or 5 other objects to accomodate that and now the install doc is out of date and the deploy script has to change and the tester has to put in a day or two trying all the combinations and permutations so we can know that code is even working. But I am also really irritated when someone else given that two hour task turns it into a half hour task by hard coding everything, even the email address it sends to, and doesn't understand when the rest of the team complains.

If there was a simple hard and fast rule, everyone could be a senior programmer the day they first compile some code. It takes experience and judgement and it's probably the most important judgement you will acquire. And you know how you get good judgement? Experience. And you know how you get experience? Bad judgement.