How extensible should code actually be? [closed]

Question

I've just started a new job and one of the things my new boss talked to me about was code longevity.

I've always coded to make my code infinently extensible and adaptable. I figured that if someone was going to change my code in the future then it should be easy to do.

But I never really had a clear idea on how far into the future that should be.

So my new boss told me not to bother coding for anything more that 3 years into the future and his reasoning was that technology changes, programs expire etc.

At first I was kinda taken aback and thought he was a whack job but the longer I think about it the more I'm warming to the concept.

Does anyone else have an opinion on how far into the future you should code to?

Sideway

Answer 1

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.

Oleaceous

Answer 2

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.

Strew

+1 @Kate, I cannot agree with you more. This is a great reply and goes a long way to explaining why I get frustrated at times. :) – Sideway

And by the time you have that experience, you are a lead and not coding anymore. And the people who are coding does not have that experience. – Meri

Perhaps where you work. I still code. And I review code :-) – Strew

Answer 3

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.

Commonalty

Answer 4

Code well, and look only to the next deliverable. Well-written code is infinitely refactorable/extensible whether written with this in mind or not. Poorly written code that is meant to be extensible rarely is in practice.

Apprise

Answer 5

If you are following Agile methodologies to the letter then you should be just coding for the current problem. This is also known as the YAGNI (You Ain't Gonna Need It) principle.

The idea is that you don't know what's coming round the corner so there's no point in trying to code for it.

However, I don't think that this is particularly sensible approach.

Even if you are in an Agile environment you have an idea of what you want the code to be able to do several iterations down the line and therefore should code to that.

While programs do expire and technologies change if you're writing that "killer" app it will be around for a lot longer than 3 years.

Determinant

Answer 6

Whenever I am coding something, I ask myself ...

Is it needed? If you don't need it, then why are you coding it?

I find it helps keep me from adding unnecessary code. Unnecessary code is a drain. It takes time away from other activities. It adds to the code size and complexity. It adds $$$ to the project--especially if the code base has to go through a certification process.

Witte

Answer 7

When designing your code, you should keep in mind possible ways that it might be extended or new functionality might be demanded of it, and you should strive to make it sufficiently modular that adding new functionality is possible. If there is a point where one decision will make it more flexible or extensible while another decision will make it more rigid, if there is little to no cost at being more flexible, then it makes sense to go with that. However, if the cost of the more flexibile route is significant, then don't do it. Unless you know for certain that you will need that feature and that the costs are justified, you should not go crazy in trying to add such functionality; if you do, you'll most likely spend a lot for nothing.

Hasdrubal