4 ms·

I like to joke that Microsoft stuff is always 80%. Works very well for the obvious use cases, but then you are bound to run into weird issues as soon as you run

by fhd2 1y ago

I like to joke that Microsoft stuff is always 80%. Works very well for the obvious use cases, but then you are bound to run into weird issues as soon as you run into some edge case they haven't covered. Makes me think it must have something to do with their corporate culture and how they work, since their developers, to my knowledge, never had a reputation for being weak. Maybe it's just because they have such a gigantic user base for everything they do, that 80% is the best business value. Though I doubt that a bit, as a third party developer, it makes me avoid their products where I can.

hulitu 1y ago
> I like to joke that Microsoft stuff is always 80%. Only when they "release" it. And then they start again from 10%. /s
- keyringlight 1y ago
  The ongoing saga with the migration from control panel to the settings app is as good an example as any. They've been working on that since win8 which released in 2012. Given the time it took to make a new release, it's been 15 years and is still ongoing, it very much seems like MS don't care about that area of the OS. I can understand that there's a lot of old/legacy third party stuff that would rely on the .cpl capabilities so you can't rip it out in one go, but "it's a lot of work" seems like a poor excuse for a company with resources like MS to not at least get all their own moved across with equivalents. They could even leave the old deprecated ones available in the background for anything legacy that needs to interact with them.
theandrewbailey 1y ago
> Maybe it's just because they have such a gigantic user base for everything they do, that 80% is the best business value. I was thinking about something similar recently. 80% of features take 20% of the time. For the hobby stuff I program, I want to make the best use of my time, so I skip the last 20% of features to make more room for stuff that matters. I call it PDD: Pareto-Driven Development. Looks like you think Microsoft is similar.
- conductr 1y ago
  They have time and resources though. I think what you say makes sense for release. At some point you just need to stop adding things and release what you could, even at their scale this is true. The pattern I see is they just never polish things after releasing them. Although, in theory, the whole team is still there available. Internally I think the culture is they immediately look to the next version. Instead of polishing what users have available, tackling the 20%, etc. So in a sense, they stay busy constantly building just the 80% part over and over again (eg, right now I imagine they’re busy porting the 80 to Windows 12 or whatever is next for them, which is probably a big rewrite because the like to change the entire style guide on each release)
duped 1y ago
I mean Microsoft has always had a reputation for shipping bad software, what that reflects on their developer teams is up to the audience. Personally I'd say it's reflective of a bad engineering culture that doesn't care about quality or craftsmanship due to lack of an incentive to ship good software but every incentive to ship software at scale, quality be damned. Like in this article alone, that's a change that should never be made. It's an understandable bug but it's indicative of carelessness, both managerial (how does this hold up to code review?) and QA (why is no one asking why login splashes take 30 seconds?).

by fhd2 1y ago

hulitu 1y ago

> I like to joke that Microsoft stuff is always 80%. Only when they "release" it. And then they start again from 10%. /s

keyringlight 1y ago
The ongoing saga with the migration from control panel to the settings app is as good an example as any. They've been working on that since win8 which released in 2012. Given the time it took to make a new release, it's been 15 years and is still ongoing, it very much seems like MS don't care about that area of the OS. I can understand that there's a lot of old/legacy third party stuff that would rely on the .cpl capabilities so you can't rip it out in one go, but "it's a lot of work" seems like a poor excuse for a company with resources like MS to not at least get all their own moved across with equivalents. They could even leave the old deprecated ones available in the background for anything legacy that needs to interact with them.

theandrewbailey 1y ago

> Maybe it's just because they have such a gigantic user base for everything they do, that 80% is the best business value. I was thinking about something similar recently. 80% of features take 20% of the time. For the hobby stuff I program, I want to make the best use of my time, so I skip the last 20% of features to make more room for stuff that matters. I call it PDD: Pareto-Driven Development. Looks like you think Microsoft is similar.

conductr 1y ago
They have time and resources though. I think what you say makes sense for release. At some point you just need to stop adding things and release what you could, even at their scale this is true. The pattern I see is they just never polish things after releasing them. Although, in theory, the whole team is still there available. Internally I think the culture is they immediately look to the next version. Instead of polishing what users have available, tackling the 20%, etc. So in a sense, they stay busy constantly building just the 80% part over and over again (eg, right now I imagine they’re busy porting the 80 to Windows 12 or whatever is next for them, which is probably a big rewrite because the like to change the entire style guide on each release)

duped 1y ago

I mean Microsoft has always had a reputation for shipping bad software, what that reflects on their developer teams is up to the audience. Personally I'd say it's reflective of a bad engineering culture that doesn't care about quality or craftsmanship due to lack of an incentive to ship good software but every incentive to ship software at scale, quality be damned. Like in this article alone, that's a change that should never be made. It's an understandable bug but it's indicative of carelessness, both managerial (how does this hold up to code review?) and QA (why is no one asking why login splashes take 30 seconds?).