March 2, 2011 at 11:15 pm
Comments posted to this topic are about the item Slow Fixes
March 3, 2011 at 3:02 am
The link to the original article is dead.
March 3, 2011 at 6:18 am
I completely agree with your assessment of the matter, Steve. Pressures do causes ISVs to chrun up patches faster, but we have seen that they are generally "band-aids" to stop the bleed, followed by the actual "fix" which follows in the next scheduled patch or service pack.
Delivering a patch, while important, is not as important as the cost incurred and the potential data issues that creep in when the fix has to be "re-patched". Instead, more time should be spent on ensuring that patches once given out do not need to change unless the architecture changes.
Another key aspect is how patches are planned - it is just like production planning in any other industry. Some ISVs may want to fix similar patterns at one go, others may want to fix a module completely before moving onto the next. Depending upon the scenario, I have used both methods, and both have yeilded fruitful results.
I will look forward to reading the thoughts of others in this discussion.
Have a great day!
Thanks & Regards,
Nakul Vachhrajani.
http://nakulvachhrajani.com
Follow me on
Twitter: @sqltwins
March 3, 2011 at 6:18 am
Actually, if you really think about it, how insane are we all to put up with patching at all? What other industry, let alone software company, do you know that can release unfinished, un-properly-tested, buggy product onto the marketplace, all driven by sales NOT quality of product?
Worse, when Microsoft knows something is highly flawed, their support people sheepishly dodge the issue and dance all around it. Its not their fault, sure, but the fact is that Microsoft is driven by sales and dollars totally leaving support staff wondering what exactly it is they are supporting.
And it gets worse... Do you know that the US Navy has rejected Microsoft Office? The Navy is staying with Office 2003 because they see NO value in (as quoted) "buying the exact same product over and over again with silly changes like the 'ribbon' to delude us into thinking its 'new' product". Microsoft does this, and gets away with it time and time again. Why? Because there is no competition in the marketplace and without competition, the 'standard' can be set so low that its nonexistent and laughable.
We, the public, accept this. Imagine if we did that with say, cars, or food. We would all be driving off the road as we slowly die from food poisoning.
Microsoft was once one of the most admired companies in America. Today many think of Microsoft as a bastion of mediocrity which has millions of users roped into purchasing unfinished, horribly documented and buggy software. And by the time the public is crying out for support, Microsoft is already building the next version which is nothing more than the same version with a new face.
It begs the famous question: Who are the fools? The fools in Redmond who dupe us regularly with crud for product, or ourselves, the idiots who just keep buying the same thing over and over and over again. A pig with lipstick on, is still a pig.
March 3, 2011 at 6:19 am
blandry (3/3/2011)
Actually, if you really think about it, how insane are we all to put up with patching at all? What other industry, let alone software company, do you know that can release unfinished, un-properly-tested, buggy product onto the marketplace, all driven by sales NOT quality of product?......
The automobile and manufacturing industries have very often done this - why do you think we have product recalls?
Thanks & Regards,
Nakul Vachhrajani.
http://nakulvachhrajani.com
Follow me on
Twitter: @sqltwins
March 3, 2011 at 6:25 am
Yes, true - but you don't go out each year and buy the same car in a different color with a dealer telling you its a "new model". And when auto companies do a recall, they fix unforseen and unplanned bugs. Microsoft ships bugs well-aware that they are there and by the time you get support, they are already working on the next version - I've been through that for over 30 years with them.
Nope, cars and manufacturing ARE similar - but they strive for quality because they have competition.
Microsoft has none, and therefore, can ship whatever they want. Ask yourself a simple question: How many MS products have had patches and Service Packs. I cant think of even one that hasn't.
Cars have occasional recalls, as do most manufactured products - once in a blue moon - for MS, its a regular habit and has been for over two decades.
That my friend is HUGE DIFFERENCE.
March 3, 2011 at 7:25 am
blandry (3/3/2011)
Yes, true - but you don't go out each year and buy the same car in a different color with a dealer telling you its a "new model". And when auto companies do a recall, they fix unforseen and unplanned bugs. Microsoft ships bugs well-aware that they are there and by the time you get support, they are already working on the next version - I've been through that for over 30 years with them.
I can't quite agree with you on that. Until quite recently, the sales cycle and warranty durations were much shorter than the design/model cycle. Even now, using lease durations as the metric, the sales cycle is still much shorter than the design cycle. Thus, if you lease the same make and model of car that you leased last time, it's extremely likely that the only meaningful changes will be mostly cosmetic: colour, aux port in the sound system to hook up your portable music player, different trim appearance, etc. In fact, even seemingly different product lines are substantially the same: there have historically been far more commonalities than differences between most models of Chevrolet, Pontiac, and Buick under GM and those all started as completely separate companies.
Also, having worked in manufacturing for many years, I can tell you that manufacturers do make 'ship with bug' kinds of decisions all the time. We know that perfection is impossible and frequently subjective (one customer's ideal is another customer's deal-killer). Compromises are made. When something fails under warranty, we try to sort it out quickly and effectively to minimize customer inconvenience, but we also try to figure out whether that warranty cost justifies the expense of working to reduce the likelihood of failure in the future.
March 3, 2011 at 8:06 am
The automobile industry (Harley Earl at GM) invented the idea of continual model changes.
“our big job is to hasten obsolescence. In 1934, the average car ownership span was five years; now it is two years. When it is one year we will have a perfect score.” (Car of the Century website)
But as far as the editorial and patch releases, I agree with the author, that it is to be expected that public issues would be addressed more quickly then issues that are known only internally.
I would like to know, in comparison to other OS manufacturers, what is the frequency of critical patches. Each of the major OSs approaches this differently.
March 3, 2011 at 10:49 am
It's not just Microsoft, it's pretty much every software vendor that follows that bug fixing process. It's basically an industry standard.
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=20746
You sometimes don't know about bugs until a user does something that they weren't expected to do. Or sometimes localization gets you, especially with Chinese and Hebrew languages. The bottom line is that unlike the automobile industry that can completely test a finite set of user actions, there will always be bug fiuxing for software because of the number of paths a user can take when using the software. This isn't so much the case with prodecural and declarative programming, but it is for object oriented and functional programming.
Joshua Perry
http://www.greenarrow.net
March 4, 2011 at 7:45 am
Of course wether or not a security flaw or bug makes public headlines determines how it is triaged, however it doesn't mean that Microsoft is just sitting on it.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply