3 ms·

Why is software so buggy?

6 points by curtis 9y ago

CM30 9y ago
I think another thing to consider (and reason that isn't brought up in this article) is that the longer a piece of software has been available to the public, the more chances there'll be for people to find bugs in it by doing things its creators would never have expected. Think about it. Let's say you're working on a CMS system for a shop, and that your startup has both automated testing processes and a specialist QA testing team. You'll find and fix quite a few bugs, but you'll then find thousands more coming in when the public gets their hands on it. Why? Because the sheer number of use cases people have will push your software to its limits. You simply can't test every 'case' someone may have for the software. Some might be using an outdated version on a newer scripting language version. On an estoteric choice of operating system. On an estoteric choice of emulated operating system via a virtual machine. With third party or self developed plugins meant to integrate with other random software. With interesting themes that may not have well thought out. You may have simply made a screw up that's only noticeable if you do ten specific things in a certain order. Or if your connection cuts out midway through a process. Or any number of factors that are incredibly hard to predict. Eventually, the reason comes down to 'it's not plausible to test every possibility and predict everything your user could theoretically do at any one time'. Heck, look at it in games terms. All those games with arbitary code execution setups only have them because someone was bored enough to try and programmatically break the game by doing about fifty seemingly random actions in ten seconds or so. Most speedrun techniques similarly only 'work' because the people who found them spend weeks or months testing random things on the off chance a wall might not hold. If there's a large enough audience, anything will be buggy.

3 ms·

Why is software so buggy?

6 points by curtis 9y ago

CM30 9y ago
I think another thing to consider (and reason that isn't brought up in this article) is that the longer a piece of software has been available to the public, the more chances there'll be for people to find bugs in it by doing things its creators would never have expected. Think about it. Let's say you're working on a CMS system for a shop, and that your startup has both automated testing processes and a specialist QA testing team. You'll find and fix quite a few bugs, but you'll then find thousands more coming in when the public gets their hands on it. Why? Because the sheer number of use cases people have will push your software to its limits. You simply can't test every 'case' someone may have for the software. Some might be using an outdated version on a newer scripting language version. On an estoteric choice of operating system. On an estoteric choice of emulated operating system via a virtual machine. With third party or self developed plugins meant to integrate with other random software. With interesting themes that may not have well thought out. You may have simply made a screw up that's only noticeable if you do ten specific things in a certain order. Or if your connection cuts out midway through a process. Or any number of factors that are incredibly hard to predict. Eventually, the reason comes down to 'it's not plausible to test every possibility and predict everything your user could theoretically do at any one time'. Heck, look at it in games terms. All those games with arbitary code execution setups only have them because someone was bored enough to try and programmatically break the game by doing about fifty seemingly random actions in ten seconds or so. Most speedrun techniques similarly only 'work' because the people who found them spend weeks or months testing random things on the off chance a wall might not hold. If there's a large enough audience, anything will be buggy.