Slashdot Mirror
When Do You Kiss Backwards Compatibility Goodbye?
Arandir asks: "Backwards compatibility is great for users. But it sucks for developers. After a while your normally sensible and readable code becomes a nightmare spaghetti tangle of conditions, macros and multiple reinventions of the wheel. Eventually you have to kiss off backwards compatibility as more trouble than it's worth. The question is, when? Should my code conform to POSIX.1 or Single UNIX 2? Should I expect the user to have a ISO Standard C++ compiler? What about those users with SunOS-4.1.4, Slackware-3.2, and FreeBSD-2.2?" This question is really kind of difficult to answer in the general sense. The best advice one can give, of course, is "when you can get away with it". Not much help, that, but the lost of backwards compatibility, like most complex decisions, depends on a lot of factors. The key factor in most developers eyes, of course, is the bottom line. Have many of you been faced with this decision? What logic did you use to come to your decision and what suggestions do you have for others who might find themself in this predicament?
Ironically I am doing it right now. Good part it is Saturday, and other developers do not know. Or they will lynch me..
<^>_<(ô ô)>_<^>
Bah, make the users conform to the developers, not the other way around!
-------------
Andy Tomaka
Abandoning backwards compatibility is often a controversial action, that needs to be carefully considered beforehand. Often, the best course of action is to consult with the Licensing Dept. They've been making great progress in the time it takes to reword licensing so that it is illegal for end users to attempt to use older hardware and/or software, often they can provide a solution in less than 3 months. This provides the Legal Dept. with a steady stream of secondary revenue, when they audit, and sometimes sue those users who call support hotlines. A win-win situation for all of us!
God created the universe in 6 days because He didn't have to worry about an installed base.
I am sure all of these Linux Java's will work fine. Can't be any compatibility issues here right? Besides anyone got a good VHDL sim in Java? Also a good finite element analysis program would be great.
JDK-1.0.2/ Wed May 6 00:00:00 1998 Directory
JDK-1.1.1/ Wed May 6 00:00:00 1998 Directory
JDK-1.1.2/ Tue May 5 00:00:00 1998 Directory
JDK-1.1.3/ Wed May 6 00:00:00 1998 Directory
JDK-1.1.5/ Tue May 5 00:00:00 1998 Directory
JDK-1.1.6/ Thu Oct 8 00:00:00 1998 Directory
JDK-1.1.7/ Sun Jun 13 00:00:00 1999 Directory
JDK-1.1.8/ Tue Aug 8 00:00:00 2000 Directory
JDK-1.2.2/ Thu Oct 19 00:00:00 2000 Directory
JDK-1.2/ Wed Aug 11 00:00:00 1999 Directory
JDK-1.3.0/ Wed Jun 13 18:05:00 2001 Directory
JDK-1.3.1/ Thu Jul 5 18:05:00 2001 Directory
Hedley
Release a set of updates, only change the minor version number, break one critical function in each update, fix it and break a different critical function in the next. Repeat until users no longer depend on the functionality that you want to change, then introduce the new functionality.
;)
But first, go read "How to write bad code," and start following those suggestions too.
I thought it is a sign. ;-)
<^>_<(ô ô)>_<^>
"Programming is like sex. Make one mistake and support it for the rest of your life."
Well Alanis, being God, was certainly smarter than you. A song named "Ironic" that didn't actually have an examples of irony - now what on earth would you call that?
Enthusiasm - I can make this baby fly!
Doubt - Something's not working here
Denial - Stating that legacy code should stay in place until the end of time.
:try_again
Anger - Showing signs of anger towards said legacy code.
Self-bargaining - Bargaining with one's self about what legacy code should stay and what should not.
Depression - Usually accompanied by guilt - When you realize you removed the wrong bit of code and checked it back in without reviewing the changes.
Acceptance - Re-writing most of the code since it's all buggered-up, anyhow.
Goto