About

About

Opinion

groff mom and you
Option Overload
No Software Engineering
UML and the Professional

Legal

Data Protection
Datenschutz
Impressum

The Option that broke the Camel's back

Recently I was reminded of an old article of Joel Spolsky, whos blog I still read from time to time, about a fight between two opposing groups at Microsoft (external link).

The gist of the article: One group at Microsoft wanted to keep (backwards) compatibility, another group didn't care that much about this and instead wanted to create

"new gigantic pieces of technology that nobody can keep up with".

Having developed rather complex, commerical software myself let me shatter all illusions of bright-eyed developers everywhere. There is no way, NO way, to keep compatibility of complex software across multiple centuries. This is an illusion. The issue isn't necessarily supporting the software the way you intended, but the way you didn't intend. Software that is rather basic, ok, fine, it may work in 100 years exactly as it did 40 years ago, but anything more complex? I highly doubt it.

Windows is now a Behemoth, with hundreds of different subsystems, frameworks and other moving parts. There is no way to keep all of this compatible. It is not a matter of willing, but a matter of practicality.

"But but but, ". Nonsense. I still have to boot up my old x200 Thinkpad with WindowsXP to play Breath of Fire IV / Final Fanatasy VII because of some strange authentication disc / reading IO something or the other. You want to tell me you can replicate this behaviour for every app out there?

Look at WineHQ for example, the (in my humble opinion) gold standard for compatibility. As of this writing (Sep 22 2020) 4996 titles are Platinum (meaning excellent compat), 4025 titles are gold (meaning good but sometimes wonky compat) and everything else (Silver - 3693, Bronze - 3013, Garbage - 4959) being basically unuseable. This took a very dedicated (and no doubt very smart) community ages to get running as smoothly as it does (and I will say I am always impressed by the WINE developers).

The following is a quote from Raymond Chen, a developer at Microsoft, whose blog is sadly no longer accessible:

I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.

If this is true, then this is horrible. How many CPU cycles have been wasted checking something which should not have been there in the first place? Would it have even been an issue? I state here that Chen's dedication to backwards compatiblity is admirable. However I also think it is in the long run unfeasable.

I think Martin Flösler said it best when he was stepping down (external link) as the KWin maintainer:

We ignore that every checkbox or option added decreases the usability for everybody else, we ignore the costs to maintain the code due to the changes. I remember that people like Björn, Kevin and Thomas told us that we should strive for satisfying 90 % of the userbase and not everyone. Currently we try to satisfy everyone. This is a road to failure in my opinion. We are on the road to KDE 3's configuration nightmare and creating an unmaintainable monster.

More and more options cannot be maintained. There is a limit to complexity - no matter how many developers you put in and how many "modules" you create. At some point you cannot put something more in without breaking something else.

Less is More

What should be done then? The next major version should have less of the old features and more of the new features. Keep keeping it simple, don't try to do everything the old version did, and focus on the new stuff. Don't have any new stuff? Then don't create a new version! But, I hear you say, I have to _sell_ something. Then sell something different. You are a smart cookie, try something else. Keep things modular, don't completely integrate everything into each other. Don't be like UML and try to take over the universe once and for all. It isn't going to work, and even if it does, it's going to suck pretty hard checking for SimCity compatibility every time you power on your smartphone.