Please participate in this poll -- the information is important.
If enough people participate, then I can point some development teams to this poll. They might find the poll results very useful.
* * * * *
Because there is limited space in the poll fields, the first answer option is meant as - "Fix only bugs first, then afterwards focus on vulnerability fixes" = fix what is already there and broken before introducing new bugs.
Consider your answer carefully -- but don't over think or over complicate the poll.
Think about this...
A.
A bug or vulnerability fix can cost a developer thousands of dollars. For example, if a bug requires 3 development team members being paid $1000 per week - and it takes 3 weeks for them to fix the bug, then the payroll expense to the developer is $9000.
B.
Developers use different scheduling methods to fix bugs and vulnerabilities. Some do it "on-the-fly" while others will adhere to a set calendar schedule. For example, in June they will fix bugs in one product, in July switch to fixing vulnerabilities in a different product - that might take two or months to fix, and then return to fixing vulnerabilities in the first product in September.
C.
Developers have a difficult time recruiting and retaining talented staff. Under-staffed development teams makes bug and vulnerability fixes a real challenge.
D.
The vast majority of bugs are merely an annoyance. Detrimental bugs (design flaws) and vulnerabilities are less common than your average, run-of-the-mill annoying bug.
E.
Generally, developers cannot concurrently fix a large number of bugs and vulnerabilities; the developer must prioritize vulnerabilities and bug fixes.
You cannot realistically expect to get both at the same time from most developers.
This is the reason there is no "Do both bug and vulnerability fixes at the same time" option in the poll.
F.
Crafting a perfect software version or build prior to release just is not possible. With the huge range of user systems and operating systems, all the variables cannot be considered.
G.
Most vendors have almost non-existent internal quality control programs that require intense, extensive testing prior to version\build releases.
That's just the way it is... and the way the industry works...
H.
Everybody wants bugs and vulnerability fixes done yesterday - which just isn't realistic. It isn't how software engineering works...
I.
More often than not, vulnerability fixes and new features introduce new bugs.
K.
A lot of vendors use Bugzilla and customize their priority codes.
For example,
C = Critical = something is not functioning and\or is a vulnerability (bypass or some failure probable) - priority fix next build\version release
A = we will try to fix it within the alotted time and available staff - but do not expect a fix earlier than 6 months or longer
B = we will try to fix it within the allotted time and available staff - but A comes first - do not expect a fix 12 months or longer
C = this will take a very long time to fix - do not expect a fix 24 months or longer
D = this will likely NEVER be fixed
If enough people participate, then I can point some development teams to this poll. They might find the poll results very useful.
* * * * *
Because there is limited space in the poll fields, the first answer option is meant as - "Fix only bugs first, then afterwards focus on vulnerability fixes" = fix what is already there and broken before introducing new bugs.
Consider your answer carefully -- but don't over think or over complicate the poll.
Think about this...
A.
A bug or vulnerability fix can cost a developer thousands of dollars. For example, if a bug requires 3 development team members being paid $1000 per week - and it takes 3 weeks for them to fix the bug, then the payroll expense to the developer is $9000.
B.
Developers use different scheduling methods to fix bugs and vulnerabilities. Some do it "on-the-fly" while others will adhere to a set calendar schedule. For example, in June they will fix bugs in one product, in July switch to fixing vulnerabilities in a different product - that might take two or months to fix, and then return to fixing vulnerabilities in the first product in September.
C.
Developers have a difficult time recruiting and retaining talented staff. Under-staffed development teams makes bug and vulnerability fixes a real challenge.
D.
The vast majority of bugs are merely an annoyance. Detrimental bugs (design flaws) and vulnerabilities are less common than your average, run-of-the-mill annoying bug.
E.
Generally, developers cannot concurrently fix a large number of bugs and vulnerabilities; the developer must prioritize vulnerabilities and bug fixes.
You cannot realistically expect to get both at the same time from most developers.
This is the reason there is no "Do both bug and vulnerability fixes at the same time" option in the poll.
F.
Crafting a perfect software version or build prior to release just is not possible. With the huge range of user systems and operating systems, all the variables cannot be considered.
G.
Most vendors have almost non-existent internal quality control programs that require intense, extensive testing prior to version\build releases.
That's just the way it is... and the way the industry works...
H.
Everybody wants bugs and vulnerability fixes done yesterday - which just isn't realistic. It isn't how software engineering works...
I.
More often than not, vulnerability fixes and new features introduce new bugs.
K.
A lot of vendors use Bugzilla and customize their priority codes.
For example,
C = Critical = something is not functioning and\or is a vulnerability (bypass or some failure probable) - priority fix next build\version release
A = we will try to fix it within the alotted time and available staff - but do not expect a fix earlier than 6 months or longer
B = we will try to fix it within the allotted time and available staff - but A comes first - do not expect a fix 12 months or longer
C = this will take a very long time to fix - do not expect a fix 24 months or longer
D = this will likely NEVER be fixed
Last edited by a moderator:
