Hacker News Reader

Comment by Alupis | Hacker News Reader

> and still chose the hard way

Chose? Unless you work on the team that made that DLL, it's likely you'd be jumping through hoops even internally.

From good source here:

You don't actually jump through hoops. All you get to do is submit the bug, which gets logged in the bucket of thousands of other bugs.

Then the PMs will gather for bug triage for the next release, which have to compete with the next shiny project features. Nobody wants to fix bugs that only one developer has. It's just not worth it. This bug has existed for years, and it is likely you could modify your code to generate different byte code.

So the bug likely won't be fixed for a while.

I love .NET. I am just describing the reality of the process of bug fixing. Also, if you fix it, who knows what else will regress. That also imposes a bias towards not fixing these kinds of bugs.

> Nobody wants to fix bugs that only one developer has. It's just not worth it. … Also, if you fix it, who knows what else will regress. That also imposes a bias towards not fixing these kinds of bugs.

This is an interesting cognitive hazard: it's relatively easy to measure the cost of paying a developer to fix a bug and possible to estimate the cost of getting it wrong but there's no way to measure the cost to everyone who encountered it but never did the work to reduce it to a testcase and file a bug report.

Worse, it's very hard to measure the cost of people who choose to use something else. Repeat that cycle a few times and a fairly high percentage of the people you will hear from are in the “never change anything less than critical” camp.

... Or also never fix anything that we won't be able to sell and make money from (this is, the next shiny thing, whatever it happens to be at the time).

The cognitive hazard is a good observation.

But I think the most important one is the imbalance of interest, which is where open source shines: MS gets zero value from fixing this bug and a lot of value from adding new features, but for this one developer this bug could have been the most important issue on the road to his company's "value" (their own product's ship date).

I wonder whether we'll see more of a hybrid model where companies either use something like Red Hat's RHEL / Fedora level of support split or a time-delayed OSS release so they can have some period of proprietary advantage while allowing customers access and allowing some chance for major outside contributions or tangents. Arguably Apple is doing something not entirely unlike that but they haven't hit the right balance yet.

i'm glad someone who works at the company like you was able to enlighten us as to microsoft's internal practices

oh wait

If you pay any attention to Microsoft, their business practices, news, reports, blogs, etc... then you would know the parent comment is pretty much spot on.

Apply some common sense, you think they let MS employees just commit to any codebase they like? And this is leaving aside all the annoying steps of locating their repository, figuring out how to build it, testing, finding out the right person to send the patch to, going through code review.

How is that any different than a central maintainer of Linux accepting patches and reviewing them before they go in?

The only difference is that you can see the source and test on your own machine first.

MS employees don't have to commit to any codebase they like, but they should be able to obtain the actual source, so that "with enough eyes, all bugs are shallow".

Actually anyone can obtain the source, it's publicly available.

Not sure why you got down voted. I know Microsoft is open sourcing chunks of .net now. Perhaps that chunk wasn't one of them?

"you think they let MS employees just commit to any codebase they like?"

That's pretty much how it works at Google. The code owners have to review and approve your change (and can reject it), but it's common (even encouraged) to commit a bugfix or new feature to someone else's project.

Actually...I heard Google has developed a lot of infrastructure to allow for this: one repository, you can submit changes that are then automatically routed for review and test and such.

It's one of the things Nadella has talked about, and plans to address over time (the extreme compartmentalism of and fierce "not made here" attitude a lot of departments/groups within Microsoft have developed over the past few decades.

On the other hand, a defense of NIH: http://www.joelonsoftware.com/articles/fog0000000007.html

There are ways to get rid of NIH without losing code quality, testings, responsibility, etc. Nadella in particular is talking about encouraging collaboration between departments.

PS: While the linked article is very relevant here, I'm getting tired of people always linking to Joel's blog -- he's not the definitive software spokesperson; has strong opinions which have been shaped by years at Microsoft - and a lot of his opinions are boxed into those views.

Reply on news.ycombinator.com