Hacker News Reader

Comment by jere | Hacker News Reader

>no tech company eats their own dog food like Microsoft

See, I've always assumed the exact opposite based on how rough the user experience is on so many Microsoft products.

I've often wondered if it was possible for a web developer at MS to sit down with IE for 30 minutes and not think "I have to fix this.... now!" When I realized how awesome Chrome developer tools were I never wanted to go back. But of course, as a web developer, you have to go back.

Or maybe that is the problem. Maybe too much dogfooding blinds you to how great the competitor is.

View on HN

Just because something is used internally doesn't mean the product manager is going to prioritize fixes for internal bug reports. Testing internally does not magically add more programmers to the project.

That's certainly true, but then dogfooding seems completely pointless if you're not going to use it to make your product better.

It just means that software engineering is difficult even with many testers.

Fixing some of the bugs you find internally doesn't mean you need to fix all of the bugs you find internally.

How about the part where you don't pay licensing to other companies? In other words, if you're developing the software anyway, may as well use it.

Sure. My first instinct is to say that's a small concern, but they do have 100k employees.

Sorry, I was introduced to "dogfooding" in Dreaming in Code. I believe there was even a chapter named after it and it was a pretty big deal about how you dogfood to maintain quality. So when I hear the term that's what I assume is implied.

While true, "the PM may not prioritize fixes", a big aspect you are missing is, someone internally with a problem has access to a direct communication line with said PM, his peers, superiors, etc.

For most day to day usage issues, dogfooding is a great way to hammer out issues. Will they find issues with every use case? No, but they will find some. Also, generally, the more diverse and large the organization, the more use cases will be dogfooded (assuming the bulk of the org is encouraged/required to do so).

When you are talking a company of 90k+, encouraged dogfooding will hit a lot of different use cases.

>"See, I've always assumed the exact opposite based on how rough the user experience is on so many Microsoft products."

And you are correct.

I remember back in the day (2005) reading about MS employees hiding their ipods when they were on campus:

http://www.wired.com/gadgets/mac/commentary/cultofmac/2005/0...

And then Steve killed everybody's buzz by banning Apple products entirely:

http://www.cultofmac.com/155131/microsoft-bans-employees-fro...

The article states that company money cannot be used to purchase Apple products, not that Apple products are banned entirely. I know plenty of people that use iPhones on campus.

Which is also bogus. There are plenty of exceptions (otherwise, how the heck does Microsoft develop Mac Office?).

In some orgs it is actually relatively easy for a PM to get a MacBook Air, for instance. You don't even need a bulletproof justification. Although with the new crop of ultrabooks, the MacBook Air is no longer so unique, so it may be more difficult.

Definitely still bogus. They have to test webapps on iPads somehow.

Apple products are not banned at MS, that's BS, in most parts of the company the most popular phone is the iPhone.

The new IE is actually pretty good. Microsoft knows that IE6 is an abomination and even made a website dedicated to its demise: http://www.ie6countdown.com/

DAMMIT CHINA!

Are you referring to 9 or 10?

My point regarding 9 is that the developer tools are buggy and painful to use compared to chrome. As a web developer, you would want them fixed as soon as possible.

MS has tons of development tools available internally that they don't release to the world. It's possible that what you're wishing you had is sitting out on Toolbox, invisible to anyone outside the firewall.

There's something of a culture of "our internal developers are smarter than our external developers" at Microsoft, so dev tools are often where the dogfooding has been the weakest. It comes from having internal developers who are hacking on things like OS kernels while the external developers have a massive population of coders churning out enterprise CRUD forms (along with a smaller population of more advanced developers), but this internal/external tool gap sometimes really bites them.

There's something of a culture of "our internal developers are smarter than our external developers" at Microsoft...

Interesting. I didn't get that impression across 4 teams, either as a PM intern or a FTE dev.

Perhaps I'm misinterpreting. But I got the impression that dev tools that qualify to be sent out into the world need to have a primary emphasis on friendliness, automation and autogeneration, and general polish. By contrast, internal tools need to be industrial grade workhorses, and if you can improve them by putting a better interface on them, that's merely nice. One of the clearest examples I can think of is the difference between their internal workhorse Source Depot and their public tool TFS (nevermind the horror that was VSS).

Like I said, I might be misreading things. And certainly the blogging community around their dev tools has improved the level of detail that goes out to developers committed enough to keep up with them.

There may be bugs, but being able to select compatibility modes from prior versions isn't something I've seen in Chrome, Safari, or Firefox.

I use web dev tools pretty hard, and I end up using both Chrome and IE Web Dev tools. They both have their strengths when you get to know them.

Actually IE6 was great when it was released.

Reply on news.ycombinator.com