Why Microsoft can't fix bugs - official.
-
I'd agree that the their Phone OS has been a disaster of epic proportions. To say they are lagging the competition in this area is probably giving them to much credit. Hopefully WP7 will start to turn that around, but it looks like they are still a step or two behind with that, but at least they've started heading in the right direction. Of course if the WP8 takes as long to get to market as WP7, they may as well shut down that division. For the most part, the rest of their products seem pretty solid, and I've definitely seen a shift to better quality and security over the last 10 years.
Jeremy Hutchinson wrote:
For the most part, the rest of their products seem pretty solid, and I've definitely seen a shift to better quality and security over the last 10 years.
Yep, that's the point I'm making. It's not the bugs. Their software is generally stable enough for me. Stability isn't why I drop kick their software into the recycle bin. Off hand I can only think of one or two bugs in Windows Media Center that bothered me. Perhaps there weren't many, or perhaps I simply didn't use it long enough to come accross more. I switched relatively quickly to Media Portal (which was buggy and slow) and ultimately to XBMC which I love. Bugs are not the problem for Microsoft. They simply are not trying hard enough to build the best apps that they could build. It's ironic that the article talks of ignoring bugs in order to add features. To me they seem to be ignoring both. They throw out sub standard run of the mill applications and expect everyone to use them simply because they are there. That might have worked in the 90's when you had to drag your sorry ass down to Egghead or CompUSA, buy an alternative and install it. Those days are gone. There is simply no excuse why a company with the resources and the platform that Microsoft had couldn't dominate The Home Theatre PC market, the Tablet Market, the Phone Market, and any other market they cared to dominate. But Hey! Nokia screwed the pooch on Smart Phones too, so perhaps it's harder than it looks to transfer dominance from one area to another. I still use windows in my HTPC, but virtually all of the software that runs on it is non Microsoft, and I'm almost at the point where my next HTPC won't run Windows. I once thought all my Development would always be on Microsoft tools, but having gotten interested in Android I'm finding myself using Java, a language that I turned my back on for years. Who knows where that will lead? Mobile changes everything. Once people get comfortable using Phones and Tablets that run Android or iPhone OS, it'll be a much smaller step for them to use something other than Windows on their Laptops and PCs. -Rd
-
Just seen How many Microsoft employees does it take to change a lightbulb?[^] in the CP daily news. A bug fix is one kind of change to the behaviour of the product, and all changes have similar costs and go through a similar process. Any new feature which does not serve a large percentage of those users is essentially stealing valuable resources that could be spent implementing features, fixing bugs or looking for security vulnerabilities that DO impact the lives of millions of people. But isn't the problem that MS involve so many people in the process that the processes outweigh the actual work? Aren't the procedures causing the problem, instead of solving it? Or is that level of involvement inevitable when a company reaches a certain size? (I stopped working for large companies a loooong time ago as I prefer to have as much flexibility as I can get) Maybe it's just me, but it all sounds like "We don't fix bugs because you don't matter to us: we have your money already".
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
You've just described what's essentially wrong with most large software development houses these days. I contend that there is a huge loss of productivity when there are too many people working on a project. Examples abound in other areas such as restaurants where a few good staff in the kitchen can deliver top quality high volume where adding just a few extra people can bring service to it's knees. I wonder if anyone has ever computed the break even point before?
“If you want to build a ship, don't drum up people together to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea” - Antoine de Saint-Exupery
-
OriginalGriff wrote:
Any new feature which does not serve a large percentage of those users is essentially stealing valuable resources
Right, so why the F did they create the Ribbon? :confused: X| :mad:
It was a pet project of the lead designer. I'm not kidding; from reading various papers I've read, the ribbon was based on a PhD thesis on UI theory and Microsoft hired this joker, but never really tested the idea in any objective way. The best UI designers I know universally find it violates many UI principles Microsoft itself established before the integrity of their UI lab was compromised. Proof to me that even Microsoft internally knew it was a bad idea is that they don't allow you to turn it off and use the traditional interface (which can almost get to using add-ons, so the base code is there.) It annoys me because I otherwise like Word 2007 (though I loathe Outlook 2007.)
-
OriginalGriff wrote:
Any new feature which does not serve a large percentage of those users is essentially stealing valuable resources
Right, so why the F did they create the Ribbon? :confused: X| :mad:
-
You've just described what's essentially wrong with most large software development houses these days. I contend that there is a huge loss of productivity when there are too many people working on a project. Examples abound in other areas such as restaurants where a few good staff in the kitchen can deliver top quality high volume where adding just a few extra people can bring service to it's knees. I wonder if anyone has ever computed the break even point before?
“If you want to build a ship, don't drum up people together to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea” - Antoine de Saint-Exupery
Couple of observations: - Eric's post is from 2003. - It's about turning down a feature request, not fixing a bug. His specific scenario occurs often, of individuals requesting features that are of particular use only to them and are not of general interest. - To emphasize his story (perhaps as a literary flourish), Eric notes that the requester notes how trivial the feature would be to implement. As Eric points out, it would be almost as trivial for the requester himself to implement. (Programming languages and frameworks are great this way.) As for the more general points: - What's the triage process MS should use for considering user requests? - How many user requests should MS implement for a product release before actually releasing that product? - Which new features added to a product in response to user requests should not be tested? What's the minimal test coverage that should be considered for adding extensions to a language like Visual Basic or C#? - Which new features should not be localized? - Which should not be documented? (FWIW, Microsoft is legally mandated by both the US and the EU to provide documentation for every public API in its products.) - Which documentation should not be localized? IOW: how do create a product like Windows or Office or Visual C# that is used by millions and millions of people every single day and have a rational development process that isn't just a matter of throwing new code into the build in response to an email from a guy who would find it really convenient if you added widget X to the next release? I'm curious whether anyone on this thread works on products that have the same install base (in as many languages) as anything that Eric works on. He's currently a senior developer on the C# team. Finally, and this intrigues me mightily: can someone cite a specific source of the idea that the Office ribbon was implemented on the whim of an academic?
mikepope
-
It was a pet project of the lead designer. I'm not kidding; from reading various papers I've read, the ribbon was based on a PhD thesis on UI theory and Microsoft hired this joker, but never really tested the idea in any objective way. The best UI designers I know universally find it violates many UI principles Microsoft itself established before the integrity of their UI lab was compromised. Proof to me that even Microsoft internally knew it was a bad idea is that they don't allow you to turn it off and use the traditional interface (which can almost get to using add-ons, so the base code is there.) It annoys me because I otherwise like Word 2007 (though I loathe Outlook 2007.)
Joe Woodbury wrote:
the traditional interface
You mean the tried-and-true-industry-standard-hasn't-failed-us-in-thirty-years interface?
-
Jeremy Hutchinson wrote:
For the most part, the rest of their products seem pretty solid, and I've definitely seen a shift to better quality and security over the last 10 years.
Yep, that's the point I'm making. It's not the bugs. Their software is generally stable enough for me. Stability isn't why I drop kick their software into the recycle bin. Off hand I can only think of one or two bugs in Windows Media Center that bothered me. Perhaps there weren't many, or perhaps I simply didn't use it long enough to come accross more. I switched relatively quickly to Media Portal (which was buggy and slow) and ultimately to XBMC which I love. Bugs are not the problem for Microsoft. They simply are not trying hard enough to build the best apps that they could build. It's ironic that the article talks of ignoring bugs in order to add features. To me they seem to be ignoring both. They throw out sub standard run of the mill applications and expect everyone to use them simply because they are there. That might have worked in the 90's when you had to drag your sorry ass down to Egghead or CompUSA, buy an alternative and install it. Those days are gone. There is simply no excuse why a company with the resources and the platform that Microsoft had couldn't dominate The Home Theatre PC market, the Tablet Market, the Phone Market, and any other market they cared to dominate. But Hey! Nokia screwed the pooch on Smart Phones too, so perhaps it's harder than it looks to transfer dominance from one area to another. I still use windows in my HTPC, but virtually all of the software that runs on it is non Microsoft, and I'm almost at the point where my next HTPC won't run Windows. I once thought all my Development would always be on Microsoft tools, but having gotten interested in Android I'm finding myself using Java, a language that I turned my back on for years. Who knows where that will lead? Mobile changes everything. Once people get comfortable using Phones and Tablets that run Android or iPhone OS, it'll be a much smaller step for them to use something other than Windows on their Laptops and PCs. -Rd
"There is simply no excuse why a company with the resources and the platform that Microsoft had couldn't dominate The Home Theatre PC market, the Tablet Market, the Phone Market, and any other market they cared to dominate." There is a excuse, its moves must be carefully thinked otherwise it will be trapped by monopoly.
-
Couple of observations: - Eric's post is from 2003. - It's about turning down a feature request, not fixing a bug. His specific scenario occurs often, of individuals requesting features that are of particular use only to them and are not of general interest. - To emphasize his story (perhaps as a literary flourish), Eric notes that the requester notes how trivial the feature would be to implement. As Eric points out, it would be almost as trivial for the requester himself to implement. (Programming languages and frameworks are great this way.) As for the more general points: - What's the triage process MS should use for considering user requests? - How many user requests should MS implement for a product release before actually releasing that product? - Which new features added to a product in response to user requests should not be tested? What's the minimal test coverage that should be considered for adding extensions to a language like Visual Basic or C#? - Which new features should not be localized? - Which should not be documented? (FWIW, Microsoft is legally mandated by both the US and the EU to provide documentation for every public API in its products.) - Which documentation should not be localized? IOW: how do create a product like Windows or Office or Visual C# that is used by millions and millions of people every single day and have a rational development process that isn't just a matter of throwing new code into the build in response to an email from a guy who would find it really convenient if you added widget X to the next release? I'm curious whether anyone on this thread works on products that have the same install base (in as many languages) as anything that Eric works on. He's currently a senior developer on the C# team. Finally, and this intrigues me mightily: can someone cite a specific source of the idea that the Office ribbon was implemented on the whim of an academic?
mikepope
Your reply, I think, was not meant to be to me but to the original poster?
“If you want to build a ship, don't drum up people together to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea” - Antoine de Saint-Exupery
-
Joe Woodbury wrote:
the traditional interface
You mean the tried-and-true-industry-standard-hasn't-failed-us-in-thirty-years interface?
Thirty years? How's the future? And if you have a time machine, why choose to use it to post on Code Project? I'd say investing in the right stocks would have been the best bet. :) (For me, the strangest thing about the Ribbon is that it's such old technology--anyone who used PCs back in the early 80s will remember several software packages that used the same concept. There were several Windows programs in the 90s that used the ribbon concept as well (HomeSite being one [and yet another package Macromedia/Adobe ruined].)
modified on Friday, September 10, 2010 12:04 PM
-
Your reply, I think, was not meant to be to me but to the original poster?
“If you want to build a ship, don't drum up people together to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea” - Antoine de Saint-Exupery
-
The article from the developer point of view makes perfect sense. The problem as I see it is who decides which future/bug fix is worth the effort and which isn’t.
The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.
-
Thirty years? How's the future? And if you have a time machine, why choose to use it to post on Code Project? I'd say investing in the right stocks would have been the best bet. :) (For me, the strangest thing about the Ribbon is that it's such old technology--anyone who used PCs back in the early 80s will remember several software packages that used the same concept. There were several Windows programs in the 90s that used the ribbon concept as well (HomeSite being one [and yet another package Macromedia/Adobe ruined].)
modified on Friday, September 10, 2010 12:04 PM
Software used menues since before the GUI revolution. And wasn't the first GUI developed in the '60s anyway? Didn't it have menues?
-
Software used menues since before the GUI revolution. And wasn't the first GUI developed in the '60s anyway? Didn't it have menues?
PIEBALDconsult wrote:
And wasn't the first GUI developed in the '60s anyway?
1973. Xerox Alto. You can see one on this very cool site: http://toastytech.com/guis/index.html[^] My point was that Microsoft not only bragged about how the ribbon was revolutionary but is (was?) attempting to patent it. Moreover, menus keep coming back because they work well and have been refined over the years. To paraphrase Churchill, menu are the worse way to navigate software features, second only to all other methods. (My biggest beef of the ribbon is that it elevates all features of a specific ribbon to equal ground when they aren't. For 99% of my work, the Home ribbon of Word, for example, could be half the height it is--how many times does anyone right justify something, change case or do strike through? They could at least let you edit the darn things. It's especially annoying because I otherwise really like Word 2007.)
-
PIEBALDconsult wrote:
And wasn't the first GUI developed in the '60s anyway?
1973. Xerox Alto. You can see one on this very cool site: http://toastytech.com/guis/index.html[^] My point was that Microsoft not only bragged about how the ribbon was revolutionary but is (was?) attempting to patent it. Moreover, menus keep coming back because they work well and have been refined over the years. To paraphrase Churchill, menu are the worse way to navigate software features, second only to all other methods. (My biggest beef of the ribbon is that it elevates all features of a specific ribbon to equal ground when they aren't. For 99% of my work, the Home ribbon of Word, for example, could be half the height it is--how many times does anyone right justify something, change case or do strike through? They could at least let you edit the darn things. It's especially annoying because I otherwise really like Word 2007.)
Joe Woodbury wrote:
Xerox Alto
Right, that thing. I can't find anything on the ribbon. I use Office 2003 at home, but at work, there's 2007 -- so I use Notepad.
-
OriginalGriff wrote:
Any new feature which does not serve a large percentage of those users is essentially stealing valuable resources
Right, so why the F did they create the Ribbon? :confused: X| :mad:
Bad example. The ribbon suits the vast (and I mean vast) majority of users.
-
Bad example. The ribbon suits the vast (and I mean vast) majority of users.
I've never met any. (But I don't get out much.)
-
Just seen How many Microsoft employees does it take to change a lightbulb?[^] in the CP daily news. A bug fix is one kind of change to the behaviour of the product, and all changes have similar costs and go through a similar process. Any new feature which does not serve a large percentage of those users is essentially stealing valuable resources that could be spent implementing features, fixing bugs or looking for security vulnerabilities that DO impact the lives of millions of people. But isn't the problem that MS involve so many people in the process that the processes outweigh the actual work? Aren't the procedures causing the problem, instead of solving it? Or is that level of involvement inevitable when a company reaches a certain size? (I stopped working for large companies a loooong time ago as I prefer to have as much flexibility as I can get) Maybe it's just me, but it all sounds like "We don't fix bugs because you don't matter to us: we have your money already".
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
eventually it all ends up like the car companies in the 70s. as one Ford manager said, " the great thing about the car industry is that you don't have to know anything about cars! " Ford survived, Chevy just barely. MS could learn a lesson here.
