interesting article about MS - continued
-
Last week I posted here a link to an interesting article (in my opinion, of course) about MS (clicky). It caused quite a discussion - thank you all guys! As a counter-argument a link to another article was posted (clicky). I read it during the weekend - definitely worth-reading. However, in the 2nd part I found something that left me speechless. It is about fixing bugs during Win2K3 development process. Let me quote it: This late in the development process, bugs are often passed along, or "punted," to the next Windows release--Longhorn--if they're not sufficiently problematic. I know that sometimes it is inevitable to release an application, even though it contains bugs that you know about. It's not a perfect world that we live in. :(. But a few lines below one can read: On the day I attended, one feature group had four of its bugs punted to Longhorn because they had failed to shown up for War Room. When someone argued that they should be given another day, Wanke simply said, "F#$% 'em. If it was that important, they would have been here. It's in Longhorn. Next bug." How can you disregard a bug because someone blew his job and didn't attend the meeting?!? "Gods die, when their believers are gone." --from Sandman by Neil Gaiman
-
Last week I posted here a link to an interesting article (in my opinion, of course) about MS (clicky). It caused quite a discussion - thank you all guys! As a counter-argument a link to another article was posted (clicky). I read it during the weekend - definitely worth-reading. However, in the 2nd part I found something that left me speechless. It is about fixing bugs during Win2K3 development process. Let me quote it: This late in the development process, bugs are often passed along, or "punted," to the next Windows release--Longhorn--if they're not sufficiently problematic. I know that sometimes it is inevitable to release an application, even though it contains bugs that you know about. It's not a perfect world that we live in. :(. But a few lines below one can read: On the day I attended, one feature group had four of its bugs punted to Longhorn because they had failed to shown up for War Room. When someone argued that they should be given another day, Wanke simply said, "F#$% 'em. If it was that important, they would have been here. It's in Longhorn. Next bug." How can you disregard a bug because someone blew his job and didn't attend the meeting?!? "Gods die, when their believers are gone." --from Sandman by Neil Gaiman
I am sure Mr. Wanke didn't blindly say chopeen wrote: F#$% 'em. If it was that important, they would have been here. It's in Longhorn. Next bug." without having at least a cursory glimpse at the bug report. And so after looking at the particular bug reports and seeing that the stakeholder didn't turn up to the meeting, he could safely assume that the issue wasn't that bad. Also remember that they probably classify features as "bugs" and this team probably realised that the feature they had requested to put into the RTM wasn't really that important anyway (i.e. they didn't punt the bugs, they just punted some features.). Chris.
-
I am sure Mr. Wanke didn't blindly say chopeen wrote: F#$% 'em. If it was that important, they would have been here. It's in Longhorn. Next bug." without having at least a cursory glimpse at the bug report. And so after looking at the particular bug reports and seeing that the stakeholder didn't turn up to the meeting, he could safely assume that the issue wasn't that bad. Also remember that they probably classify features as "bugs" and this team probably realised that the feature they had requested to put into the RTM wasn't really that important anyway (i.e. they didn't punt the bugs, they just punted some features.). Chris.
Hope you are right. "Gods die, when their believers are gone." --from Sandman by Neil Gaiman
-
Last week I posted here a link to an interesting article (in my opinion, of course) about MS (clicky). It caused quite a discussion - thank you all guys! As a counter-argument a link to another article was posted (clicky). I read it during the weekend - definitely worth-reading. However, in the 2nd part I found something that left me speechless. It is about fixing bugs during Win2K3 development process. Let me quote it: This late in the development process, bugs are often passed along, or "punted," to the next Windows release--Longhorn--if they're not sufficiently problematic. I know that sometimes it is inevitable to release an application, even though it contains bugs that you know about. It's not a perfect world that we live in. :(. But a few lines below one can read: On the day I attended, one feature group had four of its bugs punted to Longhorn because they had failed to shown up for War Room. When someone argued that they should be given another day, Wanke simply said, "F#$% 'em. If it was that important, they would have been here. It's in Longhorn. Next bug." How can you disregard a bug because someone blew his job and didn't attend the meeting?!? "Gods die, when their believers are gone." --from Sandman by Neil Gaiman
chopeen wrote: How can you disregard a bug because someone blew his job and didn't attend the meeting?!? As stated - if it was important to somebody, they'd have sorted it out and attended the meeting, or got someone else to. Linus ignores bug-patches submitted to him for Linux if he doesn't have time to look at them, and there's no way of finding out if he's included it or not until the code is released and you find your patch in there - he doesn't send feedback to patch submitters to tell them the bug is fixed. (I do have a reference for this, just not to hand.) Conclusion: All sufficiently complex software development has this class of problem, and it certainly isn't a Microsoft specific phenomenon (much as some people might like to say otherwise). Believe it or not, but punting unimportant bugs to the next version is a sensible way of managing things, particularly if you have deadlines to meet. Fixing an unimportant bug requires as much testing and verification as an important one, so punting it into the next release probably means you're less likely to break something that actaully is important. Fixing any bug is as much about risk management (in fixing this bug do I risk breaking something else) as it is providing software that works in a faultless manner - it is acceptable to ship software with bugs in, because sometimes the cost of fixing those bugs is higher than developer or customer is willing to bear, and the cost of having that bug around still is lower and managable. So to rephrase your original question, is it acceptable to move a bugfix into the next version of the software, if fixing that bug now has a knock on effect onto the rest of the software, and resulting in ultimately higher cost to the developer or customer? I believe Joel On Software has a more extensive article stating a similar thing. -- Ian Darling "The moral of the story is that with a contrived example, you can prove anything." - Joel Spolsky
-
chopeen wrote: How can you disregard a bug because someone blew his job and didn't attend the meeting?!? As stated - if it was important to somebody, they'd have sorted it out and attended the meeting, or got someone else to. Linus ignores bug-patches submitted to him for Linux if he doesn't have time to look at them, and there's no way of finding out if he's included it or not until the code is released and you find your patch in there - he doesn't send feedback to patch submitters to tell them the bug is fixed. (I do have a reference for this, just not to hand.) Conclusion: All sufficiently complex software development has this class of problem, and it certainly isn't a Microsoft specific phenomenon (much as some people might like to say otherwise). Believe it or not, but punting unimportant bugs to the next version is a sensible way of managing things, particularly if you have deadlines to meet. Fixing an unimportant bug requires as much testing and verification as an important one, so punting it into the next release probably means you're less likely to break something that actaully is important. Fixing any bug is as much about risk management (in fixing this bug do I risk breaking something else) as it is providing software that works in a faultless manner - it is acceptable to ship software with bugs in, because sometimes the cost of fixing those bugs is higher than developer or customer is willing to bear, and the cost of having that bug around still is lower and managable. So to rephrase your original question, is it acceptable to move a bugfix into the next version of the software, if fixing that bug now has a knock on effect onto the rest of the software, and resulting in ultimately higher cost to the developer or customer? I believe Joel On Software has a more extensive article stating a similar thing. -- Ian Darling "The moral of the story is that with a contrived example, you can prove anything." - Joel Spolsky
Ian Darling wrote: I believe Joel On Software has a more extensive article stating a similar thing. Hard-assed Bug Fixin' [^] Michael Blue canary in the outlet by the light switch Who watches over you Make a little birdhouse in your soul - They Might Be Giants
-
Last week I posted here a link to an interesting article (in my opinion, of course) about MS (clicky). It caused quite a discussion - thank you all guys! As a counter-argument a link to another article was posted (clicky). I read it during the weekend - definitely worth-reading. However, in the 2nd part I found something that left me speechless. It is about fixing bugs during Win2K3 development process. Let me quote it: This late in the development process, bugs are often passed along, or "punted," to the next Windows release--Longhorn--if they're not sufficiently problematic. I know that sometimes it is inevitable to release an application, even though it contains bugs that you know about. It's not a perfect world that we live in. :(. But a few lines below one can read: On the day I attended, one feature group had four of its bugs punted to Longhorn because they had failed to shown up for War Room. When someone argued that they should be given another day, Wanke simply said, "F#$% 'em. If it was that important, they would have been here. It's in Longhorn. Next bug." How can you disregard a bug because someone blew his job and didn't attend the meeting?!? "Gods die, when their believers are gone." --from Sandman by Neil Gaiman
chopeen wrote: How can you disregard a bug because someone blew his job and didn't attend the meeting?!? It depends on the severity of the bug. If the bug was a security hole, crash and easily recreatable then it would have been fixed. If the bug had been important the developers would have been at the meeting, because their manager would have made sure of it. Heck, I've held off on bug-fixes and other application changes for less, but only when the bug is judged as not serious. Michael Blue canary in the outlet by the light switch Who watches over you Make a little birdhouse in your soul - They Might Be Giants
-
chopeen wrote: How can you disregard a bug because someone blew his job and didn't attend the meeting?!? As stated - if it was important to somebody, they'd have sorted it out and attended the meeting, or got someone else to. Linus ignores bug-patches submitted to him for Linux if he doesn't have time to look at them, and there's no way of finding out if he's included it or not until the code is released and you find your patch in there - he doesn't send feedback to patch submitters to tell them the bug is fixed. (I do have a reference for this, just not to hand.) Conclusion: All sufficiently complex software development has this class of problem, and it certainly isn't a Microsoft specific phenomenon (much as some people might like to say otherwise). Believe it or not, but punting unimportant bugs to the next version is a sensible way of managing things, particularly if you have deadlines to meet. Fixing an unimportant bug requires as much testing and verification as an important one, so punting it into the next release probably means you're less likely to break something that actaully is important. Fixing any bug is as much about risk management (in fixing this bug do I risk breaking something else) as it is providing software that works in a faultless manner - it is acceptable to ship software with bugs in, because sometimes the cost of fixing those bugs is higher than developer or customer is willing to bear, and the cost of having that bug around still is lower and managable. So to rephrase your original question, is it acceptable to move a bugfix into the next version of the software, if fixing that bug now has a knock on effect onto the rest of the software, and resulting in ultimately higher cost to the developer or customer? I believe Joel On Software has a more extensive article stating a similar thing. -- Ian Darling "The moral of the story is that with a contrived example, you can prove anything." - Joel Spolsky
Ian Darling wrote: Believe it or not, but punting unimportant bugs to the next version is a sensible way of managing things, particularly if you have deadlines to meet. I know that perfectly well – I work as a tester. Ian Darling wrote: sometimes the cost of fixing those bugs is higher than developer or customer is willing to bear, and the cost of having that bug around still is lower and managable. One of the first thing I learned in the company – ‘It’s not that we can’t write perfect software. The real problem is that our customers cannot afford it’. What I wanted to stress, was not what was said but the way it was said (which suggested that they are disregarding the bug not because of its little severity but because of somebody's irresponsibility). "Gods die, when their believers are gone." --from Sandman by Neil Gaiman
-
Ian Darling wrote: Believe it or not, but punting unimportant bugs to the next version is a sensible way of managing things, particularly if you have deadlines to meet. I know that perfectly well – I work as a tester. Ian Darling wrote: sometimes the cost of fixing those bugs is higher than developer or customer is willing to bear, and the cost of having that bug around still is lower and managable. One of the first thing I learned in the company – ‘It’s not that we can’t write perfect software. The real problem is that our customers cannot afford it’. What I wanted to stress, was not what was said but the way it was said (which suggested that they are disregarding the bug not because of its little severity but because of somebody's irresponsibility). "Gods die, when their believers are gone." --from Sandman by Neil Gaiman
chopeen wrote: What I wanted to stress, was not what was said but the way it was said (which suggested that they are disregarding the bug not because of its little severity but because of somebody's irresponsibility). Which is a fair comment. But I reckon if it was an important enough bug/feature, then they'd have got on the phone to whoever it was managing it and told them to get their arse down there asap. I also think there's reason to disregard things if someone else is being irresponsible - if they missed the meeting, maybe they wouldn't be able to get the software done either. -- Ian Darling "The moral of the story is that with a contrived example, you can prove anything." - Joel Spolsky
-
Last week I posted here a link to an interesting article (in my opinion, of course) about MS (clicky). It caused quite a discussion - thank you all guys! As a counter-argument a link to another article was posted (clicky). I read it during the weekend - definitely worth-reading. However, in the 2nd part I found something that left me speechless. It is about fixing bugs during Win2K3 development process. Let me quote it: This late in the development process, bugs are often passed along, or "punted," to the next Windows release--Longhorn--if they're not sufficiently problematic. I know that sometimes it is inevitable to release an application, even though it contains bugs that you know about. It's not a perfect world that we live in. :(. But a few lines below one can read: On the day I attended, one feature group had four of its bugs punted to Longhorn because they had failed to shown up for War Room. When someone argued that they should be given another day, Wanke simply said, "F#$% 'em. If it was that important, they would have been here. It's in Longhorn. Next bug." How can you disregard a bug because someone blew his job and didn't attend the meeting?!? "Gods die, when their believers are gone." --from Sandman by Neil Gaiman
chopeen wrote: How can you disregard a bug because someone blew his job and didn't attend the meeting?!? As someone else commented what was the bug. We have that on my end. Some one in acceptance tests does not like the title on a dialog and reports it as a bug. They do not show up to state why this is important and yes we skip it. "Don't be so anti-american, would you? KaЯl (to Paul Watson on Baseball Bats) 26 Nov '03 "
-
Ian Darling wrote: I believe Joel On Software has a more extensive article stating a similar thing. Hard-assed Bug Fixin' [^] Michael Blue canary in the outlet by the light switch Who watches over you Make a little birdhouse in your soul - They Might Be Giants
From Joel On Software: Similarly I've generally given up caring about people with 16 color screens or people running off-the-shelf Windows 95 with no upgrades in 7 years. People like that don't spend much money on packaged software products. Trust me. Sounds like me ranting. Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke