7 answers
8
Questions
Asked
1253 views
How long does it usually take for bugs of a software to be fixed?
For example, video games have tons of bugs at times and it may vary because of the bug. But, what it is the usual estimated time for something to be fixed?
Login to comment
7 answers
Dan Wolf
Retired Electrical/Software Engineer and part-time College Professor (BSEET and MS Engineering Management)
129
Answers
Updated
Dan’s Answer
This is a nice question which indicates a more mature thought process on your part.
There are typically four phases of software development followed by its actual use:
1. Requirements Definition (deciding what the software must do)
2. Design (planning of the software)
3. Coding (actually writing the software)
4. Test (official testing)
5. Release to the normal users
Bugs can be created in any of the first four phases. Statistical studies have shown that any bug that slips into a later phase will take 10 times the amount of time to fix, had it been found and fixed in the previous phase. So, a bug created in the first phase that could have been identified and fixed in one hour can take 10 hours if it is fixed in the 2nd phase, or 100 hours if fixed in the 3rd phase, 1000 hours if fixed in the 4th phase or 10000 hours if fixed in the 5th phase. Think about how much it would cost to recall and repair a year’s worth of automobiles if it was determined that there was a bug in the anti-lock brake (ABS) software.
With this in mind, it is most important to “Not Create Bugs in the First Place!” so there are structured methods for writing software that reduce the odds of creating buggy software. These methods go beyond mere “learning the language syntax” and if well followed, will drastically reduce software bugs.
You can read more about this by Googling “Rule of Ten Software Development” or “software development methodologies”.
There are typically four phases of software development followed by its actual use:
1. Requirements Definition (deciding what the software must do)
2. Design (planning of the software)
3. Coding (actually writing the software)
4. Test (official testing)
5. Release to the normal users
Bugs can be created in any of the first four phases. Statistical studies have shown that any bug that slips into a later phase will take 10 times the amount of time to fix, had it been found and fixed in the previous phase. So, a bug created in the first phase that could have been identified and fixed in one hour can take 10 hours if it is fixed in the 2nd phase, or 100 hours if fixed in the 3rd phase, 1000 hours if fixed in the 4th phase or 10000 hours if fixed in the 5th phase. Think about how much it would cost to recall and repair a year’s worth of automobiles if it was determined that there was a bug in the anti-lock brake (ABS) software.
With this in mind, it is most important to “Not Create Bugs in the First Place!” so there are structured methods for writing software that reduce the odds of creating buggy software. These methods go beyond mere “learning the language syntax” and if well followed, will drastically reduce software bugs.
You can read more about this by Googling “Rule of Ten Software Development” or “software development methodologies”.
Updated
Todd’s Answer
Christopher:
This largely depends on the type of software that has the bug and the individual software publisher. For example, you mentioned video game bugs. Larger software publishers, like Sony Interactive, Ubisoft, and Santa Monica Studio, are usually fairly quick at publishing bug fixes that significantly impact game play. However, for less impactful bugs they may simply wait until the next planned major update.
Other software types, like business software, also vary in bug fix times based on a few factors. One major factor is whether the software is hosted on-premises (client/server architecture) or if it's browser-based (cloud-based architecture). As a general rule, cloud-based software is updated much more frequently. Of course, as mentioned in the above paragraph, the frequency of these bug fixes is also largely dependent on the software publisher. For instance, one software publisher I work with releases major updates 4 times per year (once a quarter), while another does it twice per year, and another does it monthly. Most cloud-based software publishers release weekly software updates that address minor bug fixes.
All of this being said, if the bug is critical enough (creates a major disruption to the software or makes the software unusable) virtually all publishers will release a fix as quickly as their software development staff can get it fixed.
I hope that helps! Great question!
This largely depends on the type of software that has the bug and the individual software publisher. For example, you mentioned video game bugs. Larger software publishers, like Sony Interactive, Ubisoft, and Santa Monica Studio, are usually fairly quick at publishing bug fixes that significantly impact game play. However, for less impactful bugs they may simply wait until the next planned major update.
Other software types, like business software, also vary in bug fix times based on a few factors. One major factor is whether the software is hosted on-premises (client/server architecture) or if it's browser-based (cloud-based architecture). As a general rule, cloud-based software is updated much more frequently. Of course, as mentioned in the above paragraph, the frequency of these bug fixes is also largely dependent on the software publisher. For instance, one software publisher I work with releases major updates 4 times per year (once a quarter), while another does it twice per year, and another does it monthly. Most cloud-based software publishers release weekly software updates that address minor bug fixes.
All of this being said, if the bug is critical enough (creates a major disruption to the software or makes the software unusable) virtually all publishers will release a fix as quickly as their software development staff can get it fixed.
I hope that helps! Great question!
Updated
Bhumika’s Answer
Only after debugging the bug, one can estimate the time, there is no rule to define the timeline for this, I hope this helps
Updated
Ivan’s Answer
Good question, under some circumstances can take long time, but due to changes on paradigms, it should take less if the developers consider including clean architectures approach and good practices, the reality is that this industry works fast, and some times fast is not synoun of good working...
but my recommendation for this is be agile, this means responsible with your work as a coder, by owning the development, includes good practices, pay atention to what other colleages are doing, specially seniors, and always ask for help if you are stuck, there are no bad questions
but my recommendation for this is be agile, this means responsible with your work as a coder, by owning the development, includes good practices, pay atention to what other colleages are doing, specially seniors, and always ask for help if you are stuck, there are no bad questions
Updated
Fred’s Answer
There is an old adage about fixing bugs. Well, there are probably many, but the one I'm thinking of is:
There are two kinds of bugs. Ones that are easy to find, but hard to fix, and ones that are hard to find, but easy to fix.
There are the occasional outliers, of course, but I think this is pretty accurate. I had a bug once that took a customer over a year to find. Then it took me a couple weeks to hunt down the issue in the code. Once I found it, the fix took about 15 seconds. But then it takes another few weeks to run it through all the testing suites, package it up, arrange with the customer when we could release it, etc.
And when I write code, there are hundreds of bugs. But that is part of the development process. I write some code, test it, find out it doesn't work, fix it, test it again, and so on. So most of the bugs never make it out of my specific environment. Once I merge my code, other people start using it, and they may find bugs. Back to me...repeat...until it makes it out of the development environment. Then the testers get it...and so on. Ultimately, my code is reviewed and tested by dozens of people and teams, with many, many bugs never making it even out of our dev/test environments.
So when is a bug a bug? Is they syntax error I make and fix a bug in your mind? or are you only talking about bugs that get released into the wild (i.e. production world)?
Ultimately, as others have said, the correct answer is "it varies wildly".
There are two kinds of bugs. Ones that are easy to find, but hard to fix, and ones that are hard to find, but easy to fix.
There are the occasional outliers, of course, but I think this is pretty accurate. I had a bug once that took a customer over a year to find. Then it took me a couple weeks to hunt down the issue in the code. Once I found it, the fix took about 15 seconds. But then it takes another few weeks to run it through all the testing suites, package it up, arrange with the customer when we could release it, etc.
And when I write code, there are hundreds of bugs. But that is part of the development process. I write some code, test it, find out it doesn't work, fix it, test it again, and so on. So most of the bugs never make it out of my specific environment. Once I merge my code, other people start using it, and they may find bugs. Back to me...repeat...until it makes it out of the development environment. Then the testers get it...and so on. Ultimately, my code is reviewed and tested by dozens of people and teams, with many, many bugs never making it even out of our dev/test environments.
So when is a bug a bug? Is they syntax error I make and fix a bug in your mind? or are you only talking about bugs that get released into the wild (i.e. production world)?
Ultimately, as others have said, the correct answer is "it varies wildly".
Updated
Jon’s Answer
Unfortunately that is wide open. A simple bug in a simple system could be discovered in 10 minutes from visually inspecting the code. A very large industrial control system with a deep timing issue could take a year to discover the flaw and months to fix. Then depending how active the system maintenance is and how many release cycles are done in a year it could take another year to get deployed.
Updated
ALi’s Answer
Hey Christopher, awesome question! The answer can be quite broad because there are loads and loads of parts that create a game. And you know what? Sometimes when you fix a bug, it might impact other sections of the "Code". Code is basically the foundation of a game (kind of like the ingredients in your favorite meal). Code works "behind the scenes". So, if you could be more specific about the bugs in the game (system), I can adjust my answer to better suit your needs.