Reducing the Edit-Compile-Test Cycle

Wed, 02 Aug 2006 04:43:30 GMT

There's a fairly obvious link between developer productivity and the edit/compile/test cycle. One of the big things wrong with Enterprise Java is that you swap the edit/compile/test cycle for an edit/compile/deploy/test cycle and one of the things right about PHP is that edit/compile/test is just edit/test.

I've previously complained about IE7 and the fact that you couldn't install IE7 with other IEs and the old tricks were reported not to work. The issue is that a good chunk of IE is embedded in the OS so randomly replacing bits of the OS with older versions gets a bit hairy. However is it really too hard for them to test a few configurations of DLLs to get it to work? It's a shame that Firefox can host a foreign IE renderer, but IE can't.

On the other hand Microsoft wants to sell you VirtualPC.

So you install an extra 1Gb of RAM, ignore Microsoft's advice about buying VirtualPC and get VMWare for free instead and set about an edit/compile/switch to vmware/test cycle. You might need to buy a copy of MSDN too because I seem to remember that it is illegal to install the same copy of XP twice on the same machine, but I could be wrong there.

DWR has been using HostedQA recently. HostedQA for me is JUnit + Cruise Control + Selenium + an army of browsers. We've been testing DWR using HostedQA for a while now and it rocks. It's helped us find bugs, and the plan is to set it up so we can test with a whole bunch of browsers so I don't even have to mess about with Firefox profiles. To a certain extent it can make the edit/compile/test cycle an edit/check-in cycle.

IE7 will make life hard for IE6 users

Tue, 07 Feb 2006 08:42:43 GMT

This sequence of events ends up with the release of IE7 being a bit of a train wreck for many users. I'm not totally sure about the logic behind this sequence of events. What do you think?

First the facts:

The renderers in IE5.5 and IE6 are broadly similar, some CSS bugs fixed, but nothing compared to the IE7 changes.
Very few people use IE5 any more.
Many web developers have got lazy and are in the habit of just testing with IE6 and ignoring IE5.5.
For the more conscientious, there is a trick to allow IE6 and IE5.5 to run on the same PC.
The .local trick doesn't appear to be working with IE7.
Web developers with bad habits from the IE6 world and those that don't have VMWare (less excuse now!), are likely just test with IE7 and ignore IE6.
IE7 breaks CSS hacks and makes big changes to the way the renderer works, so IE6 and IE7 have very different rendering engines.
New web pages that have only been tested in IE7 will probably look very bad in IE6, and there could well be a lot of them.
The uptake of IE7 will be fast for people with XP (Windows update) and slow for everyone else.

Net result: IE6 users get a web experience that gets worse over time. They blame IE and move to Firefox.

I think it would be wise for Microsoft to admit to the .local trick and make it work properly. We need a way to run multiple copies of IE without running multiple OSs.

I don't buy the "but IE is part of the OS" argument. Whatever the technicalities are - we need a way to run IE6 and IE7 side-by-side, and there are some pointers as to how to do it. Lets make it work properly.

Personally I think it's likely that IE7 will severely curtail the market-share haemorrhaging that IE is now suffering, and the browsers will sit about 85/15 or whatever for quite a while.

But anything above 10% is good enough for me. Double figures means that most websites won't be able to ignore Firefox and will be forced into the standards compliance route, and so long as we get that, the battle to force everyone down the proprietory route is for Microsoft.

Joe Walker - firefox tag

Reducing the Edit-Compile-Test Cycle

IE7 will make life hard for IE6 users