Hacker News Reader

If shit hits the fan in the .NET stack for a big enough corporate project, someone in the office can phone/email MS and get support for their problem.

That's the canard, but it has seldom worked out that way for me. Whenever I've encountered a problem that can be traced to a flaw in their products, the suggestion of calling for support is usually met with riotous laughter. (In other words, everybody says it's a selling-point of their stack, but nobody believes it.) Maybe none of our corporate projects have been "big enough". How big, exactly, does one have to be?

Edit: come to think of it, most of the problems I have seen have been things that would go against their lock-in strategies, and maybe that's where the laughter comes from. The solution is always something like waiting for hackers to reverse engineer something like NTLM, or Samba, or WINS, or exchange integration...

...or start with the official documentation coming from - gasp! - Microsoft: http://msdn.microsoft.com/en-us/library/dd208104(PROT.10).as...

I mean no offense by this (even though your condescending gasp makes me relish the thought of offending you) but you're probably too young to appreciate the requisite historical context. The link you provided is a relatively recent change in posture for the company in question.

A company I worked for in the past (MM pageviews a day, you've probably heard of them) was a big MS proponent and an early adopter of some of their new stuff, like--at the time--Silverlight. We had a fairly direct line to someone at MS if something crazy happened. It might not always get fixed right away (a bug that might need to wait for the next cycle), but MS was always on top of what needed fixing.

Contrarily, we had one guy working on some OSS stuff in a corner of the office--Apache, PHP, Rails, stuff like that. Whenever he ran into a problem that needed to be solved yesterday, he had to find and call a $100/hour consultant who may or may not even be able to solve the problem, or even guarantee that it would be patched at a later date. That's the big MS selling point.

"MM pageviews a day, you've probably heard of them) was a big MS proponent and an early adopter of some of their new stuff, like--at the time--Silverlight."

Yes, and that's about what it takes to get attention. Especially the "early adopter of Silverlight", you probably had a dedicated team back at MS.

And there are other large companies that also rise to this size. What confuses me is the 30-person ISV that believes that they can get magical super awesome support from Microsoft. They can't, or at least nothing better than they can get from open source. And typically, I find they know it too; they know better than to try to contact Microsoft, yet they still hold the mythical ability to do so in their hands like a security blanket. That's what confuses and to some extent annoys me; saying "I can get support from MS" when it's true makes sense, but using that as a reason to use MS when it's not is just silly.

It's a big selling point and that's legitimately true, but unless you're absolutely huge it doesn't apply to you.

Wow. We are a 10 person company (entire company, not just dev staff), and we had a major issue and I called MS and the issues was fixed in 2 days. And no, it wasn't some wierd setting or some hotfix that was already available, it was a bug in 2008 R2. Minidumps, remote sessions, and long conference calls for 2 days, but they ended up providing some files in the end to work around it until the next patch.

How about one person? I recently had an issue with VS 2010 and long hangs in the editor for a specific type of file. I got a series of minidumps for them... we narrowed it down to an issue with type resolution.

They sent me a QFE drop and then incorporated the fix into a tools release they were doing.

I was acting as single dev, not even on a support contract.

I think I need that fix. Thanks for reporting it!

Yes. This is what the open source world doesn't understand. You can't just copy a commercial product feature-for-feature, open source it and then scratch your head wondering why it isn't gaining adoption.

When a corporate pays for software, they are paying for peace-of-mind and assurance more than the bits that make up the app.

That's true for Office and software packages like Webmail.

But if you build a system using Microsoft's tools and you ask for support, they'll tell you that the problem is with your code, not their tools. They'll support issues with your web server, database server, and even your IDE, but when it comes to the code itself, there's no level of support they can truly offer.

This is from 10 years of personal experience working in an MS centric organization. I get as much support on my Ruby code from MS as I get for the ASP code I wrote. None.

But people up the chain don't get this - they think "if we use the MS stack, we can blame them when something goes wrong."

I'll gladly take $200,000 a year from a company so they can feel like they can blame me when their apps don't work. I'll just charge them so many points per issue, have them run some diagnostics tool I send them, and say "you have a problem with your code. Can't help you."

But that's what your post's parents are talking about. Microsoft won't debug your code, but they will respond if you show them a bug in their code (and you've paid for the support accounts).

I was replying specifically to "When a corporate pays for software, they are paying for peace-of-mind and assurance more than the bits that make up the app."

The peace of mind part. And that support contract still hasn't provided a fix for the padded oracle exploit. It'll be "a few weeks yet."

Unfortunately this sort of view isn't very compatible with the indie developer ideal, or the ideals the author holds--which might one of the many reasons why you see so much Rails/PHP development in the non-enterprise space.

I'd say a much more likely reason is that the enterprise can't get enough programers to support anything other than the MS stack. The culture at large enterprise simply isn't compatible with the hacker mindset. Banks are a notable exception in my mind, but then again banks have always been fairly agile when it comes to turning a profit.

Also, the open source ideal isn't an "indie developer" ideal. Serious systems engineering goes on in the open source community and it produces what often are the technically superior solutions.

> If a bug is found in the stack itself, it won't languish unsolved in bug trackers for years, like many OSS bugs do. MS will probably fix it in their next cycle

You also have the option of paying Microsoft for a QFE (quick fix engineering). With a QFE, the team fixes the bug as an immediate priority and provides you with a patch for it. All QFEs eventually get rolled up into cumulative updates and/or service packs.

So I'm paying to fix a bug in their software that I've already paid for?

Call me crazy, but if I have the option of cracking open the stack and having a go at fixing the bug myself I'll do it. At least that way I'm not dependent on anyone else for the fix...

Hey I didn't say it's a good option, just that it's an option :) The whole "paying someone to fix their bug" always boggled my mind. But it's the reality of MS and the reality of many of their customers. It works for them, so more power to them. I guess.

How much does it cost you to divert your attention to fixing someone else's bugs?

It's all just a question of economic efficiency. Being able to pay for priority bugfixes is efficient.

>> If a bug is found in the stack itself, it won't languish unsolved in bug trackers for years, like many OSS bugs do.

Oh, please...

Over the years, I've personally fixed bugs. And sent in fixes. (Stop complaining -- I promise to send tests too, next time!)

If I run into one that I am unable to grok in a reasonable time, there are always job boards and money.

Bugs -- not to be confused with full sized features -- are generally not that big a problem in even non-popular open source. You don't have to decompile the damn code!!

And you can get bugs fixed without waiting for a new release, next year... maybe.

>>Over the years, I've personally fixed bugs. And sent in fixes. (Stop complaining -- I promise to send tests too, next time!) >>If I run into one that I am unable to grok in a reasonable time, there are always job boards and money.

That's fine for a smaller shop, or even a medium-sized shop. But when you enter a true corporate behemoth type company, you don't have the option of posting an ad on the 37signals job board and hoping a dev cowboy will show up the very next morning and fix your problem. There's HR hoops to jump through, budgets to watch, schedules to keep, managers and colleagues to keep appeased--that's the kind of red-tape stuff that makes hiring anyone, even a short-term freelancer, enough of a PITA to not bother.

And as a corporate dev, you have better things to do than waste time hunting, fixing, merging, and patching a piece of software that should really only be a black-box cog in your greater machine.

Shouldn't the first rule of writing good software be "nothing is a black box"?

At some point something in that box is not going to work how you expect it to, regardless of who makes it.

Too bad most mega-corporations aren't as concerned with writing good software as they are with staying on budget, meeting deadlines, and making money. Not to say the two are mutually exclusive, but BigCorp isn't going to want to pay for your time to learn how Apache's threading model works so that you can beat a race-condition bug in PHP's IMAP library (or whatever).

OK, a reality check.

First, threading problems in Apache? That is something you report on a mailing list and it gets fixed fast. It is an actively developed application (-: at least last I looked, lots of years ago :-).

Second, I am a consultant that do work for a mega corporation, which builds large systems. At least thousands or developers. I don't know (and am too lazy to Google.)

I don't know because I work in a small group of developers and seldom interact with large groups of others. Most other developers I interact with in this mega corp also work in quite small groups. Big groups often seems to consist of small groups.

When I run into bugs/limitations in an open source library and write a work around (and send in the fix), the manager of my group in Big Corp is happy with me, since I fixed a problem. (His managers probably only hears from him "I'm happy with that consultant despite his humor and personality, keep him".)

Now, all this might be different in the Windows world. But when I was there a bit, ten++ years ago, you could find competent people.

(Have I been trolled?)

To be clear, the threading example was just something off the top of my head, not an actual real-life example. Though the PHP IMAP library is not thread-safe, so the problem would be fixing that library (or learning the guts of it to work around it in certain cases), not Apache. The point is that the example itself doesn't matter.

Finally, all of the big companies I've worked for have been MS shops for the reasons I've stated. Of course not every company is going to be the same. But every one I've worked for wants the MS "guarantee" because they'd rather pay their devs to build their product, not to fix bugs in someone else's software.

I'm pretty confused as to why these comments have been downvoted so much. Just because someone else's company uses OSS successfully doesn't invalidate the justifications for using MS that I've experienced.

>>To be clear, the threading example was just something off the top of my head,

That is OK, since I just skimmed the example and saw problems with Apache/PHP std lib.

It was just stupid. Lots of people use those -- and bugs are killed fast.

In absolute worst case, use an external program in another language for this. (Processes or threads doesn't matter.)

That works, since IMAP4 was new and shiny in the mid 90s(!) -- in the non-MS world, we don't replace functioning standards all the time so there are multiple implementations out there for e.g. email libs...

>>I'm pretty confused as to why these comments have been downvoted so much.

Because you only know one side of things -- and believe the propaganda about the other side.

If you're not trolling me and are generally confused, here is where I'm coming from.

I think the confusion is that I work for a big corp that do software as a central part of their business -- I'm not writing applications with shiny buttons on administrative applications (desktop or web) ordered by monkeys in suits.

I'm here to write lots of functionality and teach people. For that, we use scripting, open systems that are flexible -- and pluggable. I can always change what I plug in, with the limitation of having to teach people.

If it was the best solution, we would e.g. add a Windows machine and script Excel. The main problem would be that stuff in Microsoft applications tend to work badly in the next version and it is a f-ing pain and waste of money to rewrite stuff you implemented well a couple of years ago.

(Lots of other people here work as army ants on big projects where they should be replaceable. They use Java or C++, deploying little to Windows. I do server apps, not embeddable here, since I love the speed of creating functionality with Lisp, scripting languages etc.)