What are the most common reasons for lack of forward compatibility

Question

Some companies, like Blizzard, make software that continues to work well in future versions of Windows and with newer versions of their other software dependencies. Other companies (mostly ones that are not hardcore software companies) sometimes write software that breaks with a release of a new OS or other software dependency. What do the hardcore software companies know that the others don't? What are the major causes for forward compatibility problems?

Answer 1

Did Blizzard write software that works well with future versions of Windows (Starcraft still plays on 7 for example)...

or did Microsoft write "future versions" of software that is backwards looking?

Something like WoW isn't exactly "forward looking" since it's still in active development. Other software, like Starcraft/Warcraft/Diablo was written for the time and happens to still work because MS goes out of its way to enable old software on new systems.

Blizzard also has the ability, and reason, to update its old games. Very popular titles that drive its current software.

Some software uses hackish/non-standard parts that don't work well. Unique setups, reliant on "old" bugs to operate, drivers that aren't ported to new systems, etc.

Answer 2

Several reasons:

1. They write to standards that continue to be supported in future OS's
2. OS companies (e.g. MS) actually put in a good deal of code to support older software
3. Large popular software houses tend to have formal or informal relationships with the OS companies, so they get to see stuff earlier.

Answer 3

Here's my experience: Many years ago, a product that I worked on started supporting third-party plugins. We'd send a request to the plugin, which it was supposed to reply to. The first parameter in the plugin was a number which identified which request we were making. At that point there was only one request. Still we documented that you should check this number, and if it was a number that you didn't understand, do nothing but return an error code with the meaning "I don't understand this request". Simple enough. The first version on our side handled this correctly. Even when sending the first request (the only one we could ever send) we checked whether the plugin responded "don't understand" and handled it.

Then we added the second request. Tested with old plugins expecting they would respond "I don't understand this request". All plugins performed the action for the first request. That's not forward compatible :-( These plugins had been shipped to customers and would crash with a new app version.

What we did: Put the software into a context where the first request could be performed without damage. Sent a totally different request. If the response wasn't "don't understand" then we knew from then on that the plugin was written by idiots and no requests other than the one we developed first were made.

Answer 4

You can't ensure 'forward compatibility', it is up to the OS and HW makers. The best thing you can do when writing software is to ensure you aren't using deprecated features or non-standard tricks.

Answer 5

I think it's just that writing forward compatible software takes more effort. Whether the effort (=cost) is worth the compatibility must be evaluated by the releasing firm.

For example, database schemas can change. They could be migrated automatically (for best user experience) or ignored (for less development effort).

Answer 6

Some programmers read the documentation and write code that use the OS in the way the documentation tells them to. Other programmers write code quicker and debug any code that does not work.

A good example will be code that can’t cope with windows having a two digit version number; it will not fail testing on Windows 8, but when used on Windows 10…..

Then you have games that are written to be as fast as possible, bypassing the OS not caring if they will work in a few years time…..

Take a programmer that leaned to program working on Unix software in the days that each vendor has its own version of unit, that programmer will be very used to reading the standards and ONLY depending on what the standards say. As having to ship your software on 6 different versions of Unix teaches you quickly to be careful. Compare this with a programmer that learned on VB, where it is common to just change the code until it works…… But put the “Unix type programmer” on the same task as the “VB type programmer” and often the person that learned on VB will produce a result that can be sold a lot quicker.

When interviewing staff, people tend to choose like minded people, so once a company has their first few staff, new staff tend to think the same way.

Answer 7

I would think the main reason for lack of forward compatibility would be the dearth of working programmers who also happen to be clairvoyant.