10 ms·

Full Disclosure: I worked at M$ from 2014-2015. MS has some very talented programmers. They're not very common, but they exist. The problem is that the entire

Full Disclosure: I worked at M$ from 2014-2015. MS has some very talented programmers. They're not very common, but they exist. The problem is that the entire company is completely and totally focused on developing an absurd number of new features and products, giving them completely unrealistic deadlines, and then shipping software on those deadlines no matter how half-assed or buggy it is. The idea is that everything is serviceable over the internet now, so they can just "fix it later", except they never do. This perpetuates a duct-tape culture that refuses to actually fix problems and instead rewards teams that find ways to work around them. The talented programmers are stuck working on code that, at best, has to deal with multiple badly designed frameworks from other teams, or at worst work on code that is simply scrapped. New features are prioritized over all but the most system-critical bugs, and teams are never given any time to actually focus on improving their code. The only improvements that can happen must be snuck in while implementing new features. As far as M$ is concerned, all code is shit, and the only thing that matters is if it works well enough to be shown at a demo and shipped. Needless to say, I don't work there anymore.

cm2187 11y ago
I think it's largely a dog fooding problem. Visual Studio is a superb piece of software, and you can tell that its designers are the primary users. Microsoft's consumer apps are awful.
- njloof 11y ago
  Visual Studio is superb? It's still a 32-bit app that crashes in daily usage.
  - JBReefer 11y ago
    I know there's a strong VS counterjerk, but nothing else comes close. I've been using it for years and all of its crashes have been 100% my fault. I know IntelliJ is great, and JetBrains in general rocks, but it's no contest.
    - creshal 11y ago
      > all of its crashes have been 100% my fault. Wait, what? Why is it okay if a program crashes at all?
      - random_rr 11y ago
        ... can you show me a program you've written that accepts complex developer input and literally never crashes?
        creshal 11y ago
        Microsoft shouldn't be held to the same quality standards as a hobby programmer.
        random_rr 11y ago
        Okay, but what I'm saying is that you are holding them to an impossible standard. If you believe perfect programs exist, I've got news for you. Development environments in particular may have to crash sometimes in order to prevent the user from wrecking everything else on the system.
        gelasio 11y ago
        OK then let's compare VS to XCode, which doesn't even have half the features of VS and crashes twice as much. If not, which comparable product would you pick?
      - JBReefer 11y ago
        Running tons and tons of VS instances while debugging broken, memory hogging programs, modifying the XML for weird project types for third party plugins poorly, etc. Things that MS really can't do anything about.
        douche 11y ago
        I've never seen a GUI form builder that really worked that well, but the WinForms and especially WPF builders are huge dogs. Less said about the old-fashioned WebForms GUI, the better...
  - cptskippy 11y ago
    In comparison to other IDEs it is superb. As far as the 64/32 bit argument, it's pretty absurd. What are the benefits of going 64 bit? More memory consumption? (http://blogs.msdn.com/b/ricom/archive/2015/12/29/revisiting-64-bit-ness-in-visual-studio-and-elsewhere.aspx http://blogs.msdn.com/b/ricom/archive/2015/12/29/revisiting-...) What types of apps are you developing in Visual Studio? It's my daily driver and crashes very rarely for me.
    - reitanqild 11y ago
      > In comparison to other IDEs it is superb. I thought most serious users of VS had to install ReSharper on top of it?
      - cptskippy 11y ago
        I guess I'm not a serious user then because I've never used ReSharper anywhere I've worked.
      - Someone1234 11y ago
        Most "serious" users are now uninstalling ReSharper. Visual Studio 2015 adds most of ReSharper's key perks and JetBrains has done little or nothing to resolve ReSharper's laggy/hoggy/unstable code (and has said they aren't going to re-write it for Roslyn). Honestly back in VS 2010 I'd call ReSharper a core tool. In VS 2015, eww.
        reitanqild 11y ago
        Thanks, appreciated. I honestly thought it still was like this.
      - WorldMaker 11y ago
        I've never liked ReSharper, have felt that the "advice" it offers is often over-rated and seems commonly to be wrong for C# (not unexpected given that JetBrains primarily focuses on Java outside of ReSharper, I feel like ReSharper is a Java developer's approach to C#). These days what's baked into VS and the Roslyn compiler platform blows ReSharper out of the water. Just about everyone I've worked with that had daily complaints about how slow and laggy they felt Visual Studio was didn't seem to understand that ReSharper was 99% of the slow-down, excessive memory use, and UX lag...
  - Digit-Al 11y ago
    Not moving to 64 bit has been a pragmatic decision [1]. As for crashing, I used it for over 10 years at my previous company and it never crashed once. At my current company it only crashes when I am using the Stylevision plug-in, which is really, really, buggy. [1] http://blogs.msdn.com/b/ricom/archive/2009/06/10/visual-studio-why-is-there-no-64-bit-version.aspx http://blogs.msdn.com/b/ricom/archive/2009/06/10/visual-stud...
    - criddell 11y ago
      That pragmatic decision was made 7 years ago. A lot has changed since then and I don't think the arguments hold up. What developer machine doesn't have at least 16 GB of RAM these days?
      - gelasio 11y ago
        Did you even read the article? The arguments still hold up. It's clearly the case that it's not worth the effort to move VS to 64-bit. - "First, from a performance perspective the pointers get larger, so data structures get larger, and the processor cache stays the same size. That basically results in a raw speed hit..." - "The cost of a full port [due to the amount of code involved, not the quality of the code] of that much native code is going to be quite high and of course all known extensions would break and we’d basically have to create a 64 bit ecosystem pretty much like you do for drivers. Ouch." - "A 64 bit address space for the process isn’t going to help you with page faults except in maybe indirect ways, and it will definitely hurt you in direct ways because your data is bigger...32 bit processes accrue all these benefits just as surely as 64 bit ones."
      - sblom 11y ago
        And they have current benchmarks that indicate that it's still the right decision: http://blogs.msdn.com/b/ricom/archive/2015/12/29/revisiting-64-bit-ness-in-visual-studio-and-elsewhere.aspx http://blogs.msdn.com/b/ricom/archive/2015/12/29/revisiting-...
        criddell 11y ago
  - jlhim 11y ago
    i'm not sure what you are doing wrong. i use it 8 hours every day and this does not happen.
  - GnarfGnarf 11y ago
    I've been using various versions of Visual Studio since 1999. I can count on one hand the number of times it has crashed, usually coincident with me doing something unwise.
    - thought_alarm 11y ago
      Most things in VS run in-process (that was the case circa mid-2000s, at least). It only takes one bad component to bring the whole thing down, and there are many, many, many components.
  - Merad 11y ago
    IME, Visual Studio crashes are almost always due to misbehaving plugins. I'm in it all day every day, and once or twice a week it will develop some quirk that requires a restart to fix, but I can't remember the last time it actually crashed. The only plugins I run are Resharper, Xamarin, and PTVS.
  - its2complicated 11y ago
    I've never experienced VS crashing, but Intellisense stops working EVERY time I use VS! :)
  - chrisbennet 11y ago
    Daily? VS2015 hasn't locked up on me in a couple of days. ;-) Even with locking up once or twice a week, it's pretty awesome.
- mark-r 11y ago
  Funny though that Visual Studio insists on defaulting to upper case menus. That must be a decision forced on them by a PHB somewhere, which just tells you that nobody is immune from the organizational rot.
  - cm2187 11y ago
    And an all grey interface. Which the visual studio team managed to reverse partially. The Windows 10 team: not so lucky...
  - chris_wot 11y ago
    Oh, I positively lurve the Microsoft design team's justification for all caps: When we shared the RC design preview with you, we expected the uppercase menu would generate mixed feedback and emotions. We had seen similar reactions from early adopters and from our own internal users prior to posting about it. [1] So then they said they had been "thinking about it" (why a lot of thinking was necessary is beyond me), and that "using uppercase for the menus was not an arbitrary decision" because they needed "to keep Visual Studio consistent with the direction of other Microsoft user experiences". Then they tried to say that "some of you" won't like the change and that these people have "been very direct in expressing your opinions on this subject". In other words: they got told it was an absolutely awful decision from the very start by beta testers and their own test team, but ignored it because, well, "consistency". Then they released it and they got almost total user revolt, but they can't back out now because, well, "consistency". But they now allow you to change to letter case with a registry tweak, after all - Microsoft know better than their end users, even when those end users are screaming for them to change a fairly fundamental UX error. http://blogs.msdn.com/b/visualstudio/archive/2012/06/05/a-design-with-all-caps.aspx http://blogs.msdn.com/b/visualstudio/archive/2012/06/05/a-de...
  - flurpitude 11y ago
    Visual Studio 2015 does not have upper case menus.
    - mark-r 11y ago
      That's good news! I'm still on 2013 for now.
userbinator 11y ago
It's not just Microsoft, but this "update culture" is pervasive in software today. New features make for exciting marketing but in the end what most users probably want more is stability. All the stories of forced updates and accompanying reboots (with not even a chance to save work?) remind me of the old criticisms of Windows being so unstable it needs to be rebooted frequently, and how uptime was a highly-valued result of good system design. I personally think near-daily updating to fix bugs that should've been discovered and fixed before actually shipping product is absurd. It's been argued that this is because systems are more complex now, but maybe we don't actually need all that complexity...
- vmateixeira 11y ago
  Yes, I can also see that happening in many other companies. I think that this urge on putting something new out quickly (Innovation?), regardless of being stable or not, is what they think they can win market with. And sure they can.
  - fla 11y ago
    Yup, It is a way to add more 'perceived value' than there actually is. Lowering the investment required for creating something that _seems_ worthy enough for people to buy it. From a customer perpective, it looks like an evil spiral more and more companies tend to fall into. Edit: wording
  - marcosdumay 11y ago
    This might be yet another enterprise trap set-up by the fact that the people deciding what software to buy are different the people paying for the software and different from the people using the software. The problem is that Windows isn't a purely enterprise product. Although it gets little money from the end user market, it needs dominance on that market for strategic reasons. So, MS will ensure it dominates end user market, whatever it takes.
- FollowSteph3 11y ago
  Most users say they want stability but when it comes to actually paying, unfortunately most users will only pay for features, especially new shinny ones that demo well. This is the challenge faced by software companies.
deleted 11y ago
[deleted]
krylon 11y ago
There is a very interesting book, "I Sing The Body Electronic" by Fred Moody, who had the opportunity to observe a team at Microsoft very intimately over the course of a project. Back then, apparently part of the problem was that good managers were very rare, and as the company grew and grew, they put people in management positions that were not really qualified for (or comfortable with) the job. Deadlines appear to have been a problem back then, as well. I have wondered, how much of that has changed since. From your description, not much... :(
jfuhrman 11y ago
Why do you refer to MS as M$? In my experience the people who do that are far from the people who worked or would work at MS. https://www.penny-arcade.com/comic/2002/07/22/m https://www.penny-arcade.com/comic/2002/07/22/m
- Joof 11y ago
  Have you ever seen how much Microsoft will pay you? Those sort of people often end up as very good programmers. Not that surprised that people in this camp end up working at Microsoft and then quit because they don't like working there.
- blackhole 11y ago
  I only started referring to MS as M$ after I had been working there for a year. I joined them with cautious optimism, because the new CEO had finally gotten rid of that atrocious stack ranking system. That optimism did not last long. I only stayed there as long as I did because of how much they were paying me. Referring to them as "M$" is disturbingly appropriate given that all they do is to throw huge amounts of money at problems until they go away. After seeing what goes on inside that company, I immediately tried to move to Linux, but it just isn't practical (http://itvision.altervista.org/why.linux.is.not.ready.for.the.desktop.current.html http://itvision.altervista.org/why.linux.is.not.ready.for.th...). At the very least, I won't be upgrading to Windows 10 until 2020.
Qwertious 11y ago
So, Microsoft has forgotten the concept of technical debt? That's hilarious. Also sad. Wasn't it Joel Spolsky (a former Microsoft employee) who actually coined the term "technical debt"?
- mark-r 11y ago
  Ward Cunningham coined the term "technical debt" according to Wikipedia. He worked for Microsoft for a short period of 2003-2005, but this was long after the term was invented.
reubenbond 11y ago
I also previously worked for Microsoft (Azure Active Directory). We took code quality very seriously. All new features required at least 80% code coverage from tests before commit (not a particularly high bar, but a pragmatic one). New features also required a test plan + review covering stress/perf, unit, integration, & system tests. Many features required threat models which were reviewed with the security team. Progress/bugs were reviewed weekly at ship room. Live site issues were reviewed the next morning (involving the relevant on-call engineers). So as with any large company which isn't a monoculture, things vary from team to team. Also, calling them "M$" in 2016?
yuhong 11y ago
What do you think about http://www.networkworld.com/article/2866286/microsoft-subnet/former-microsoft-chief-privacy-officer-on-the-cloud-conspiracy.html http://www.networkworld.com/article/2866286/microsoft-subnet... I suspect the culture still exist today.
deleted 11y ago
[deleted]

cm2187 11y ago

I think it's largely a dog fooding problem. Visual Studio is a superb piece of software, and you can tell that its designers are the primary users. Microsoft's consumer apps are awful.

njloof 11y ago
Visual Studio is superb? It's still a 32-bit app that crashes in daily usage.
- JBReefer 11y ago
  I know there's a strong VS counterjerk, but nothing else comes close. I've been using it for years and all of its crashes have been 100% my fault. I know IntelliJ is great, and JetBrains in general rocks, but it's no contest.
  - creshal 11y ago
    > all of its crashes have been 100% my fault. Wait, what? Why is it okay if a program crashes at all?
    - random_rr 11y ago
      ... can you show me a program you've written that accepts complex developer input and literally never crashes?
      - creshal 11y ago
        Microsoft shouldn't be held to the same quality standards as a hobby programmer.
        random_rr 11y ago
        Okay, but what I'm saying is that you are holding them to an impossible standard. If you believe perfect programs exist, I've got news for you. Development environments in particular may have to crash sometimes in order to prevent the user from wrecking everything else on the system.
        gelasio 11y ago
        OK then let's compare VS to XCode, which doesn't even have half the features of VS and crashes twice as much. If not, which comparable product would you pick?
    - JBReefer 11y ago
      Running tons and tons of VS instances while debugging broken, memory hogging programs, modifying the XML for weird project types for third party plugins poorly, etc. Things that MS really can't do anything about.
      - douche 11y ago
        I've never seen a GUI form builder that really worked that well, but the WinForms and especially WPF builders are huge dogs. Less said about the old-fashioned WebForms GUI, the better...
- cptskippy 11y ago
  In comparison to other IDEs it is superb. As far as the 64/32 bit argument, it's pretty absurd. What are the benefits of going 64 bit? More memory consumption? (http://blogs.msdn.com/b/ricom/archive/2015/12/29/revisiting-64-bit-ness-in-visual-studio-and-elsewhere.aspx http://blogs.msdn.com/b/ricom/archive/2015/12/29/revisiting-...) What types of apps are you developing in Visual Studio? It's my daily driver and crashes very rarely for me.
  - reitanqild 11y ago
    > In comparison to other IDEs it is superb. I thought most serious users of VS had to install ReSharper on top of it?
    - cptskippy 11y ago
      I guess I'm not a serious user then because I've never used ReSharper anywhere I've worked.
    - Someone1234 11y ago
      Most "serious" users are now uninstalling ReSharper. Visual Studio 2015 adds most of ReSharper's key perks and JetBrains has done little or nothing to resolve ReSharper's laggy/hoggy/unstable code (and has said they aren't going to re-write it for Roslyn). Honestly back in VS 2010 I'd call ReSharper a core tool. In VS 2015, eww.
      - reitanqild 11y ago
        Thanks, appreciated. I honestly thought it still was like this.
    - WorldMaker 11y ago
      I've never liked ReSharper, have felt that the "advice" it offers is often over-rated and seems commonly to be wrong for C# (not unexpected given that JetBrains primarily focuses on Java outside of ReSharper, I feel like ReSharper is a Java developer's approach to C#). These days what's baked into VS and the Roslyn compiler platform blows ReSharper out of the water. Just about everyone I've worked with that had daily complaints about how slow and laggy they felt Visual Studio was didn't seem to understand that ReSharper was 99% of the slow-down, excessive memory use, and UX lag...
- Digit-Al 11y ago
  Not moving to 64 bit has been a pragmatic decision [1]. As for crashing, I used it for over 10 years at my previous company and it never crashed once. At my current company it only crashes when I am using the Stylevision plug-in, which is really, really, buggy. [1] http://blogs.msdn.com/b/ricom/archive/2009/06/10/visual-studio-why-is-there-no-64-bit-version.aspx http://blogs.msdn.com/b/ricom/archive/2009/06/10/visual-stud...
  - criddell 11y ago
    That pragmatic decision was made 7 years ago. A lot has changed since then and I don't think the arguments hold up. What developer machine doesn't have at least 16 GB of RAM these days?
    - gelasio 11y ago
      Did you even read the article? The arguments still hold up. It's clearly the case that it's not worth the effort to move VS to 64-bit. - "First, from a performance perspective the pointers get larger, so data structures get larger, and the processor cache stays the same size. That basically results in a raw speed hit..." - "The cost of a full port [due to the amount of code involved, not the quality of the code] of that much native code is going to be quite high and of course all known extensions would break and we’d basically have to create a 64 bit ecosystem pretty much like you do for drivers. Ouch." - "A 64 bit address space for the process isn’t going to help you with page faults except in maybe indirect ways, and it will definitely hurt you in direct ways because your data is bigger...32 bit processes accrue all these benefits just as surely as 64 bit ones."
    - sblom 11y ago
      And they have current benchmarks that indicate that it's still the right decision: http://blogs.msdn.com/b/ricom/archive/2015/12/29/revisiting-64-bit-ness-in-visual-studio-and-elsewhere.aspx http://blogs.msdn.com/b/ricom/archive/2015/12/29/revisiting-...
      - criddell 11y ago
- jlhim 11y ago
  i'm not sure what you are doing wrong. i use it 8 hours every day and this does not happen.
- GnarfGnarf 11y ago
  I've been using various versions of Visual Studio since 1999. I can count on one hand the number of times it has crashed, usually coincident with me doing something unwise.
  - thought_alarm 11y ago
    Most things in VS run in-process (that was the case circa mid-2000s, at least). It only takes one bad component to bring the whole thing down, and there are many, many, many components.
- Merad 11y ago
  IME, Visual Studio crashes are almost always due to misbehaving plugins. I'm in it all day every day, and once or twice a week it will develop some quirk that requires a restart to fix, but I can't remember the last time it actually crashed. The only plugins I run are Resharper, Xamarin, and PTVS.
- its2complicated 11y ago
  I've never experienced VS crashing, but Intellisense stops working EVERY time I use VS! :)
- chrisbennet 11y ago
  Daily? VS2015 hasn't locked up on me in a couple of days. ;-) Even with locking up once or twice a week, it's pretty awesome.
mark-r 11y ago
Funny though that Visual Studio insists on defaulting to upper case menus. That must be a decision forced on them by a PHB somewhere, which just tells you that nobody is immune from the organizational rot.
- cm2187 11y ago
  And an all grey interface. Which the visual studio team managed to reverse partially. The Windows 10 team: not so lucky...
- chris_wot 11y ago
  Oh, I positively lurve the Microsoft design team's justification for all caps: When we shared the RC design preview with you, we expected the uppercase menu would generate mixed feedback and emotions. We had seen similar reactions from early adopters and from our own internal users prior to posting about it. [1] So then they said they had been "thinking about it" (why a lot of thinking was necessary is beyond me), and that "using uppercase for the menus was not an arbitrary decision" because they needed "to keep Visual Studio consistent with the direction of other Microsoft user experiences". Then they tried to say that "some of you" won't like the change and that these people have "been very direct in expressing your opinions on this subject". In other words: they got told it was an absolutely awful decision from the very start by beta testers and their own test team, but ignored it because, well, "consistency". Then they released it and they got almost total user revolt, but they can't back out now because, well, "consistency". But they now allow you to change to letter case with a registry tweak, after all - Microsoft know better than their end users, even when those end users are screaming for them to change a fairly fundamental UX error. http://blogs.msdn.com/b/visualstudio/archive/2012/06/05/a-design-with-all-caps.aspx http://blogs.msdn.com/b/visualstudio/archive/2012/06/05/a-de...
- flurpitude 11y ago
  Visual Studio 2015 does not have upper case menus.
  - mark-r 11y ago
    That's good news! I'm still on 2013 for now.

userbinator 11y ago

It's not just Microsoft, but this "update culture" is pervasive in software today. New features make for exciting marketing but in the end what most users probably want more is stability. All the stories of forced updates and accompanying reboots (with not even a chance to save work?) remind me of the old criticisms of Windows being so unstable it needs to be rebooted frequently, and how uptime was a highly-valued result of good system design. I personally think near-daily updating to fix bugs that should've been discovered and fixed before actually shipping product is absurd. It's been argued that this is because systems are more complex now, but maybe we don't actually need all that complexity...

vmateixeira 11y ago
Yes, I can also see that happening in many other companies. I think that this urge on putting something new out quickly (Innovation?), regardless of being stable or not, is what they think they can win market with. And sure they can.
- fla 11y ago
  Yup, It is a way to add more 'perceived value' than there actually is. Lowering the investment required for creating something that _seems_ worthy enough for people to buy it. From a customer perpective, it looks like an evil spiral more and more companies tend to fall into. Edit: wording
- marcosdumay 11y ago
  This might be yet another enterprise trap set-up by the fact that the people deciding what software to buy are different the people paying for the software and different from the people using the software. The problem is that Windows isn't a purely enterprise product. Although it gets little money from the end user market, it needs dominance on that market for strategic reasons. So, MS will ensure it dominates end user market, whatever it takes.
FollowSteph3 11y ago
Most users say they want stability but when it comes to actually paying, unfortunately most users will only pay for features, especially new shinny ones that demo well. This is the challenge faced by software companies.

deleted 11y ago

[deleted]

krylon 11y ago

There is a very interesting book, "I Sing The Body Electronic" by Fred Moody, who had the opportunity to observe a team at Microsoft very intimately over the course of a project. Back then, apparently part of the problem was that good managers were very rare, and as the company grew and grew, they put people in management positions that were not really qualified for (or comfortable with) the job. Deadlines appear to have been a problem back then, as well. I have wondered, how much of that has changed since. From your description, not much... :(

jfuhrman 11y ago

Why do you refer to MS as M$? In my experience the people who do that are far from the people who worked or would work at MS. https://www.penny-arcade.com/comic/2002/07/22/m https://www.penny-arcade.com/comic/2002/07/22/m

Joof 11y ago
Have you ever seen how much Microsoft will pay you? Those sort of people often end up as very good programmers. Not that surprised that people in this camp end up working at Microsoft and then quit because they don't like working there.
blackhole 11y ago
I only started referring to MS as M$ after I had been working there for a year. I joined them with cautious optimism, because the new CEO had finally gotten rid of that atrocious stack ranking system. That optimism did not last long. I only stayed there as long as I did because of how much they were paying me. Referring to them as "M$" is disturbingly appropriate given that all they do is to throw huge amounts of money at problems until they go away. After seeing what goes on inside that company, I immediately tried to move to Linux, but it just isn't practical (http://itvision.altervista.org/why.linux.is.not.ready.for.the.desktop.current.html http://itvision.altervista.org/why.linux.is.not.ready.for.th...). At the very least, I won't be upgrading to Windows 10 until 2020.

Qwertious 11y ago

So, Microsoft has forgotten the concept of technical debt? That's hilarious. Also sad. Wasn't it Joel Spolsky (a former Microsoft employee) who actually coined the term "technical debt"?

mark-r 11y ago
Ward Cunningham coined the term "technical debt" according to Wikipedia. He worked for Microsoft for a short period of 2003-2005, but this was long after the term was invented.

reubenbond 11y ago

I also previously worked for Microsoft (Azure Active Directory). We took code quality very seriously. All new features required at least 80% code coverage from tests before commit (not a particularly high bar, but a pragmatic one). New features also required a test plan + review covering stress/perf, unit, integration, & system tests. Many features required threat models which were reviewed with the security team. Progress/bugs were reviewed weekly at ship room. Live site issues were reviewed the next morning (involving the relevant on-call engineers). So as with any large company which isn't a monoculture, things vary from team to team. Also, calling them "M$" in 2016?

yuhong 11y ago

What do you think about http://www.networkworld.com/article/2866286/microsoft-subnet/former-microsoft-chief-privacy-officer-on-the-cloud-conspiracy.html http://www.networkworld.com/article/2866286/microsoft-subnet... I suspect the culture still exist today.

deleted 11y ago

[deleted]