![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jenkJoel on Software posted this a while ago, I just stumbled on it today via Raymond. Joel details quite a few reasons for why the 97-03 formats are complicated and how to avoid having to read/write them directly. But I1 thought this quote was particularly telling:
Now, I'm not used to thinking about the .doc and .xls files in those exact terms m'self. Most of the apps I work on these days are a lot smaller and have a lot less code than Word or Excel. And yet, every one has some field or feature that isn't used much now, but is around (if only so the app will work if you pull up the older records that used it) and they do tend to trip up devs who are trying to maintain the app. Especially new devs who don't know it's even there! (Smart testers will, of course, feature these things on the regression test. ;)
Backward compatibility headaches are everywhere in software. The longer your app has been around and the more users it has, the more headaches you have.
1Speaking as someone who did not work on Office but did work on such backward-compatible concerns as DOS and Windows. I did work with the Office 97 team during IE 5, which enabled me to learn how different the Office team processes/methods were from the IE team (and from the Windows team of which IE was a part).
Every checkbox, every formatting option, and every feature in Microsoft Office has to be represented in file formats somewhere. That checkbox in Word’s paragraph menu called “Keep With Next” that causes a paragraph to be moved to the next page if necessary so that it’s on the same page as the paragraph after it? That has to be in the file format. [...]
A lot of the complexities in these file formats reflect features that are old, complicated, unloved, and rarely used. They’re still in the file format for backwards compatibility, and because it doesn’t cost anything for Microsoft to leave the code around. But if you really want to do a thorough and complete job of parsing and writing these file formats, you have to redo all that work that some intern did at Microsoft 15 years ago. The bottom line is that there are thousands of developer years of work that went into the current versions of Word and Excel [...] A file format is just a concise summary of all the features an application supports.
Now, I'm not used to thinking about the .doc and .xls files in those exact terms m'self. Most of the apps I work on these days are a lot smaller and have a lot less code than Word or Excel. And yet, every one has some field or feature that isn't used much now, but is around (if only so the app will work if you pull up the older records that used it) and they do tend to trip up devs who are trying to maintain the app. Especially new devs who don't know it's even there! (Smart testers will, of course, feature these things on the regression test. ;)
Backward compatibility headaches are everywhere in software. The longer your app has been around and the more users it has, the more headaches you have.
1Speaking as someone who did not work on Office but did work on such backward-compatible concerns as DOS and Windows. I did work with the Office 97 team during IE 5, which enabled me to learn how different the Office team processes/methods were from the IE team (and from the Windows team of which IE was a part).
