How extensible should code actually be? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

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?

---

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.

---

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.

---

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.

---

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.

---

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.

---

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.

---

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.