Hacker News Reader

Comment by antics | Hacker News Reader

---Author here---

I should disclose that I actually work for Microsoft, and still chose the hard way. Fuck the police!

For sure, those who complain about Microsoft not being open source are obviously trying to cover the fact that they are bad at reading assembly language.

Obviously?

That's the key word that should let you know an attempt at humor was imminent.

Obviously.

That, and they're too poor to buy IDA Pro.

> 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

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.

"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.

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?

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.

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.

Off topic, but I really enjoyed your post about writing a Python lexer/parser in Haskell. Thanks for that!

http://blog.nullspace.io/obvious-python-parser.html

Thanks! I really appreciate it! :D

You chose the really hard way, the reference source is public - http://referencesource.microsoft.com :P

---Author here---

It wasn't that hard. It took us about 30 minutes (thanks largely to the fact that Bart is a genius.) Besides, that's not actually the source of this DLL. We are on .NET native, and for that matter, a bleeding-edge build that's only available here at MS.

Out of curiosity, would you have been able to read the actual source if you wanted?

Microsoft already publishes the source code for the .net framework (and I think other projects like asp.net and mvc) at referencesource.microsoft.com

They do, but interestingly that particular assembly is not included. Or at least I couldn't find it there.

The namespace appears to have changed or something, I found it here:

http://referencesource.microsoft.com/#System.Core/Microsoft/...

Note: also MSFT employee, don't work on .NET though.

---Author here---

I work at MS, and we're using a slightly exotic version of this DLL. Please pardon the differences. :)

---Author here---

Yeah, I've never tried, but I have a copy of the actual Windows source tree, so I'm guessing the answer is yes.

And an extension called Ref12 will also allow you to browse to the online code from Visual Studio.

Aren't you allowed to send a git (err tfs) pull request there at least within the company?

I've read several places that even Microsoft is not standardized on a source control management, some use tfs, some svn, some git, etc.

Don't think of MS as a single monolith. They're a hundred businesses of various sizes that just happen to share the same HR department.

> use tfs, some svn, some git, etc you can go onto MS's job board and find Rails, iOS, and Node positions. :-D

Different VCS is suited to different things. Perforce is great for gargantuan codebases with strong oversight requirements. Git is a poor choice if you check in lots of binaries. SVN is pretty widespread and supported natively by a lot of tools.

I know of some teams even still using visual source safe for legacy reasons.

Reply on news.ycombinator.com