Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Ricky writes "Many wonder why Microsoft doesn't offer nightly builds of Internet Explorer — or at least something more frequent than months-to-years. Ars talks with Microsoft's general manager for IE, who says the IE9 development cycle will look much the same as previous versions. Not a great idea."

For the same reason Apple doesn't release nightly builds of Safari? (Yes, I understand they release nightly builds of Webkit).

Nobody else uses Trident (IE's rendering engine), and if Trident breaks, a lot of other stuff in Windows breaks. They don't want to release development versions of their browser, because their corporate customers don't want users breaking things.

Frankly, I'm wondering what benefit nightlies would have for MS, who does pretty much all of their testing in-house.

Which is, of course, precisely the reason to have a meaningful suite of automated tests and frequent build/test cycles. You'd rather work 6 months on something and then throw it over the wall to testers only to have them come back with either hundreds of regression failures (best case) or a handful of failures so severe they couldn't even get past the basic smoke test script?

That's even before you get to your user community, which as the article poi

Which is, of course, precisely the reason to have a meaningful suite of automated tests and frequent build/test cycles.

The story doesn't say that MS doesn't have nightlies and automated tests internally (I don't know how it is for IE specifically, but I am virtually certain that they do in fact have both; I would be very surprised if any MS project in development stage didn't have either).

You're right, we don't know what the IE development team has or doesn't have. Still, what's the point of going to all the trouble to create a good automated build/test/release system and not have frequent deliveries to the end users - the web development community in this case? I've seen teams do that, and over the life of the project it felt like a net loss because the time and effort spent babysitting the build was wasted because break in the feedback loop by not getting it to end users meant that what w

My "why" was really more of a rhetorical question. In my experience, setting up and maintaining an automated build/test/deploy for a complex thing like IE is quite a lot of work, and I'm not sure any team would benefit from the effort if the only benefit was just keep the build from breaking. That could be done by having a designated team member manually build the system whenever there was time (hah) and a need to check it. No, to make a frequent build worth the effort, you need to get the resulting softwar

The better question would be why Ricky believes not releasing nightly builds is "not a great idea". What part of Microsoft's standard development cycle would benefit from nightly builds? Why would Microsoft decide to release nightly builds, which are inherently unstable, to a public that loves to pick on MS for producing unstable software? Why would MS risk some bored journalist writing a hit piece on IE 9 based on a particularly faulty nightly build just on the off chance someone out in the ether might give them some useful feedback on it?

Yeah... my main thought initially was “they’re Microsoft – they don’t need a reason,” but that was only very shortly followed by “how on earth would that benefit them, us, or anyone else for that matter?”

I believe it comes from the update server (which is basically contacted by nightlies every so often to see if there's an update to the next nightly, just like other builds contact it to see if there's an update). Then you extrapolate from the number of update checks. It's a rough estimate, of course; as are all usage numbers.

And maybe I'm confusing the nightly and beta, of course! If I find the source where I saw the number, I'll comment.

Developing apps to use in the wild means that the end-users will find all sorts of ways to do the wrong thing. These are not things you can always test for before a release (beta, rc, whatever), unless you do double-blind usability using people who've never used your software.

I've come to expect that when I release a new version of whatever or add/change a feature, I will get immediate feedback from the field because someone will add a new URL to a list that passes my v

As somebody who has frequently participated in beta tests of lots of software, including Microsoft's, this is spot-on. Sure, their infrequent betas get some good feedback and some good bug reports, but they also get absolutely drowned in a deluge of people on the discussion boards (newsgroups, actually) who complain about:A) Nothing particular at all, they just signed on to complain.B) Stuff that's completely unrelated to the beta (such as a complaint about IE6 on the IE8 beta discussion)C) Stuff that's completely unrelated to the product (complaints about Excel on the IE8 board)D) "How dare Microsoft release [a beta of] this product with such-and-such [known, sometimes in release notes] bug!"E) "WTF I installed the latest version of X, and now I can't access my Y, so I'm switching to competitor Z and never buying anything Microsoft again!"F) Complaints about Beta 1 bugs during Beta 2 or RC test phases.G) Complaints from people who installed the software on a production machine, and expect Microsoft to provide support for it.

These are the types of morons that Microsoft has to deal with. I've seen some of this type of behavior in other betas, to be sure, but some of the problems, especially D, E, and G, are most common on the MS betas. People just seem to expect that any code from MS will be production-ready and expects the company to stand behind their software as though it were a released product.

Microsoft would be *insane* to release nightly builds to a group like that. A closed beta nightly program, maybe (participants culled from those who are actually useful and productive on the public beta) but certainly not open. Especially considering point F above; people already can't always keep up with the pace of the infrequent releases, and asking them to identify the build number they're using would be an exercise in futility for far too many.

What does MS offer nightly builds for??? It's just not how they work. They're a typical monolithic development house that deals only with releases and occasionally lets beta code out. There are benefits to the approach like not trying to shoot a moving target when it comes to bugs etc. People who've grown up with agile seem to think it's the only way to do quality assurance.

Microsoft saves up the feces, and savors it in their intestines for months and years. That lets it get really stinky and, well, shitty. Then, in one big blast, they crap it out all over everybody. That's just their way.

The open source community prefers to rub a quick one off each night. Rub rub rub and the load has been blown.

So it all depends on what you prefer. Would you rather get nightly blasts of jizm in your face, or would you prefer

The major difference is that rubbing a quick one off actually encourages a premature release cycle and your users end up gradually getting less satisfied with your performance and go elsewhere...
No matter how many dumps you take, it doesn't affect the performance of the next one:)

Believe it or not, waterfall is not the only alternative to agile. In fact, your comment represents one of the biggest critisms of agile. It misrepresents the alternatives and in many ways seems more like a religion than a development methology.

How's that constantly changing never quite know what you're building agile shitfight working for you?

It works quite well, actually, when you have frequent releases to the user, because they can say "yes this is good" or "no this isn't good", and only OCD types really worry about knowing exactly what's what at any time. In fact, software projects tend to delude themselves into thinking they know what they've got when they really don't. This leads to all kinds of problems later when the users see it and find out that what they got is nothing like what they were told they were going to get.

Excellent. So as a developer you're not just rude, abusive and unprofessional, you're also a one trick pony who worships at the alter a single methodology, and have an uncanny knack for convoluted useless metaphor. Please file your resume here in the filing cabinet marked "Waste bin". Don't let the door hit your arse on the way out. I'd really like to think you're just trolling but unfortunately I have had the misfortune of working with your ilk before.

...only OCD types really worry about knowing exactly what's what at any time...

Not all software has the same cost of failure. If a particular bug can cost tens of thousands of dollars, I sure as hell want to know exactly what releases had that bug. There's nothing OCD about this desire.

The vast majority of companies with nightly builds to NOT give those nightly builds to customers. They're for internal testing and to make integration of changes easier to manage. Nightly builds will almost always have unfinished or untested features; because if everything was complete and tested then they may as well tag it as an official release.

The vast majority of companies with nightly builds to NOT give those nightly builds to customers.

I know of one, who does so, apparently quite successfully. I played golf this summer with their director of Q/A. I'm struggling to remember their name and what they do, but it was some web based SaaS offering with 300-ish employees in downtown Seattle (we were playing golf at Willows Run, which is just down the street from Microsoft Intergalactic in Redmond). We got to talking agile, and releases, and he said

ROFL! The only thing you know about agile is that is is a buzzword, that's it.

Wow. You're an amazing person. You must be very well paid to be able to work out how much I do or do not know about agile from a single post. Yes that was sarcasm. In case your too obtuse it means I think you're a wanker and you know nothing about me.

My company uses agile effectlively, and everyone knows that agile is comprised of iterations (typically 1, 2, 4 weeks or whatever you want).

the reality is that every other browser has a more regular release cycle than IE does, and that keeps them relevant.

I guess Opera's release and development cycle(s) is why it is so popular!

The result is a strong perception that IE is lagging behind, no matter how great the major release versions are.

The perception that IE is lagging behind has nothing to do with a bad development cycle, it's more tied to... bad development and a not-very-good product.

and the browser's updates are pushed through Windows Update. The actual browser doesn't have its own updating system, and this is a large part of the reason that over 40 percent of users are still using IE6 and IE7.

That's an interesting assertion. The only backup he gives are numbers for browser stats.

On the whole, this seems like one guy doing an editorial and talking off the cuff. That's how it struck me, anyways.

The perception that IE is lagging behind has nothing to do with a bad development cycle, it's more tied to... bad development and a not-very-good product.

And opening up the process with, perhaps, a chance to incorporate feedback early in the process is a great way to address this. You want to give people what they want? be more responsive and don't cast the featureset in stone based on whatthe product manager says.

I guess Opera's release and development cycle(s) is why it is so popular!

Actually, Opera doesn't have nightlies. Weeklies at best most of the time. And there's no "bleeding-edge" build available. They have the next major version cooking apparently, but they aren't sharing anything until they have exhausted 10.x it seems. Firefox and Chrome, on the other hand, have nightlies of both current and future releases.

WTF? Most companies don't release nightly builds of their software. Why on earth are we singling out Microsoft, and only one of their products at that? Infrequent releases are the norm, not the exception, and while you may argue that it should change, it's ludicrous to single out one program among thousands for following the standard practice.

Presumably because, while IE is quite similar to the class of "proprietary software", it is quite unusual among the desktop browsers.

Whether or not you think that it is a good idea for there to be IE nightly builds, it isn't exactly absurd to judge a product by the standards of other similar products, rather than other products with similar licenses.

You can get nightlies from other browsers, but if you're not a developer or tester, why would you want to? You're just going to get buggy software that way. Firefox makes sense, because it's an open source browser and depends upon customers to also be testers.

Testing is a job. Asking the public to do the internal development testing doesn't work if you want to earn a living selling software (or the software ecosystem). I haven't seem many nightly builds of the Mac OS, or lots of other for sale software.

Webkit is a rendering engine. Its pretty useless without supporting code. The link you gave links you to a loadable library essentially. The app icon you get for OSX actually runs a script that has Safari use the webkit library from the package, but the UI and everything else is still the same old Safari thats installed on the system.

If someone bothered to put the effort into it, you could stuff IE's renderer into Safari on Windows,

Chromium is not Chrome. They may share a common tree, but they aren't the same either. Chrome may be built from a snapshot of the chromium tree, but that doesn't give you nightlies of chrome.

Okay, what kind of logic is that? A nightly is by definition a daily build that's a snapshot of the development trunk, which official releases are eventually built off of. The Chrome developers themselves use Chromium for development. It's a nightly build in every sense of the term.

Even if for some reason you don't buy that logic, Chrome has a Dev Channel, which releases official Google-branded Chrome builds every week or so. So, it still has weekly builds.

As a key product in a proprietary OS, why would you want to run nightly builds of IE? With Firefox my browser may be unstable, but at least the rest of my system stays stable, but with IE a lot of Windows components use Trident and that isn't going to be a good thing. Plus, with Firefox if you file a bug they appreciate that and generally fix it right away, even security vulnerabilities aren't promptly fixed on IE, let alone user suggestions....

The IE guys are going to have to fix any problems in how it plays nice with Windows anyway, and if the development process is so broken that they can't even keep O/S-breaking regressions out of the builds, there's a problem. The whole point of having frequent builds is to identify errors sooner, while it's cheaper and easier to fix them, than later, after the edifice has been built on the unstable foundation.

with Firefox if you file a bug they appreciate that and generally fix it right away, even security vulnerabilities aren't promptly fixed on IE, let alone user suggestions....

I suggest that's the whole point of wanting IE to have a more frequent build and release cycle -- ge

The IE guys are going to have to fix any problems in how it plays nice with Windows anyway, and if the development process is so broken that they can't even keep O/S-breaking regressions out of the builds, there's a problem.

The problem is that IE is tightly coupled with several other Windows components. This means it can break many other apps which can depend on it, or also can break itself if it depends on something which is not available.

A monolithic blob of pieces that have tight coupling between each other and leak those dependencies to other pieces that shouldn't even KNOW about another applications dependencies in the first place is bad software engineering. Again, the article is correct in urging the frequent build/test/release to the public cycle because it would highlight the dependency errors quickly and allow them to be fixed before they become a problem. We all know DLL hell (or RPM hell -- linux doesn't get a pass here, either) a

As a key product in a proprietary OS, why would you want to run nightly builds of IE? With Firefox my browser may be unstable, but at least the rest of my system stays stable, but with IE a lot of Windows components use Trident and that isn't going to be a good thing.

WebKit is heavily used in OS X too, AFAIK, but they still provide nightlies. It doesn't replace the existing version on your system, it's an extra one that you can manually run as part of specific programs. So you'd use the nightly build to test, but other programs would keep using the standard system build.

It also doesn't have to be called "Internet Explorer". It could be called something different, like "Trident Development Version" or something. Firefox nightlies are called Minefield.

Plus, with Firefox if you file a bug they appreciate that and generally fix it right away

Why is the finger always at Microsoft? I vote we embargo the use of the word Microsoft on Slashdot, say, for a month. Usually any Microsoft related post is biased and ill-spirited - getting very old.
There are countless software vendors that do not release nightly builds.
As much as I adore Slashdot, all the MS haters on here often make me feel as if I'm associating myself with a 'new low' of computer users (sometimes). Kinda like finding yourself in the company of a bunch of racists. It's very fashionable on \. to hate Microsoft. Don't like their stuff?...simply use something else and STFU.
I do agree with the article's opinion of saying the update process Microsoft uses is broken - I think Microsoft can do better.

Because many of us use their stuff and despair at the problems that arise that we cannot fix and the Microsoft will ignore.That creates a culture of just complaining to each other about the company in general. We say to each other things like "this was the company that was given the BSD source code on a plate and still couldn't get even ping right" and other things non-techies would find completely irrelevent.Just filter the MS stories out - there's not going to be muc

While I think Microsoft is right with its release cycle, the article is based on the fact the every other browser vendor is releasing snapshots.

For me, the biggest picture is interaction and strategy, not builds. In Webkit, Gecko and Presto, if you are a web developer, you can interact with the engine developer. They have mailing list, good bucktrackers, and a *good attitude* towards fixing bugs.

For Microsoft, if you are using Linux for development (a pretty common case I'd guess) you cannot even try. I dou

The Microsoft build labs has been described in many books but one thing that stood out to me was the alleged fact that most builds, like Windows, take well over 24 hours to finish. Given how tied into the operating system that MSIE is, I suppose that a build of MSIE would require a significant build of Windows as well.

Given how tied into the operating system that MSIE is, I suppose that a build of MSIE would require a significant build of Windows as well.

I find it highly unlikely. In the end, IE lives in its own library, and any OS services that may need it call through that via stabilized COM interfaces. There's no reason why Windows can't be build against precompiled IE binaries and.idl files describing the interface, and similarly no reason why IE can't be built against the most up-to-date Windows SDK headers.

I am not a fan of Internet Explorer at all - however I know people who are, and I can't imagine this mattering to them in the least.

Heck, I can't imagine the vast majority of Firefox or Safari/Chrome users caring about those available snapshots; and I say that as someone who has used nightly builds for both those products fairly frequently!

This just seems silly on the face of it. "Microsoft doesn't follow Firefox's development path", complains a Firefox fan.

It' not like IE is open for people to download the nightly builds. I'm sure that Microsoft and its employees compile IE many times even though it might not be on the "nightly build" schedule in the most official sense.

I would assume that the Microsoft Excel team did it this way as well, since Joel mentions it in his article. But they also wrote their own compiler [joelonsoftware.com] because everyone else's was crap, and still managed to ship on time.

As an IT Manager for one of the 100 biggest companies in the world, I couldn't give a flying f*ck about the inbetween. All I want to know is what we're getting. And if it breaks a part of our fundamental application stack, we'll complain or won't use it. If I want something in the release, I'll lobby for it. If you want to be part of the IE development cycle, sign an agreement with MS to be a part of it, then you'll get the alphas and beta.

Maybe you hadn't noticed, but development of IE7 and IE8 have not been tied to a specific OS at all. IE7 was released before Vista and installs on XP, and IE8 well before Win 7 and that installs on Vista and XP. Microsoft has said that IE9 will be released in 2010, while Windows 8 is set for 2012. IE and Office are both on different development timetables than Windows -- although Office is almost always released 6 to 8 months after a desktop Windows release. Sure, they're linked in some senses because e

A long release schedule ensures that Microsoft has to find and squash every bug themselves to make a single presentable product that will have a better reputation than your average nightly build. It ensures developers see only a stable standard and worry that this year's version will have different quirks than last year's version and that they won't find out until it is too late to do anything except hack workarounds for the browser bugs into their site. What harm would nightly releases cause Microsoft [e

Microsoft releases Alfas and Betas to many different communities of testers

And those releases have multiple cycles and run a long time so there is ample opportunity for developers of dependent s/w and web pages to test against the coming release and provide feedback to Microsoft. How many builds of W95 did I load...including one from floppies that took 20+ hours of feeding floppies before the first boot.

I wonder if Microsoft might just have as many in-house testers using the daily builds of IE as there are