Why Microsoft can't fix bugs - official.
-
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.
