I'm at Microsoft's MIX conference in Las Vegas, where the big news has been the unveiling of the Windows Phone 7 development platform, and the platform preview of Internet Explorer 9 with extensive HTML 5 support.
There is more to say about both topics; but one thing I want to highlight is that IE9 will not work on Windows XP, the venerable release that will not die.
It is not only that XP remains in use on existing PCs; there are also new machines on sale with this old version of Windows. I've just purchased a netbook, and when making my selection I noticed that many of them still come with XP, usually the Home edition. Some companies still specify XP when buying new PCs, to avoid the compatibility hassles that come with a move to Vista or Windows 7. There's also doubt over the benefits of upgrading. A friend said to me recently, "I really like XP, it does everything I need. What is the point of moving?"
Here's what IE General Manager Dean Hachamovitch told me:
Building a modern browser requires a modern operating system. There are facilities in Windows Vista and Windows 7 around security, for example the integrity level work that gave us protected mode, there are performance improvements that enable a variety of things in the browser, there is graphics infrastructure to take advantage of the GPU, that doesn’t exist in previous operating systems.
A measure of scepticism about such comments is reasonable. Microsoft wants users to buy its latest stuff; there's no surprise there.
Nevertheless, Hachamovitch is right. Windows 7 is more secure and more powerful. Personally I find it easier to use as well, partly thanks to Microsoft's design work on the user interface, and partly because desktop composition in Windows Aero enables richer preview of minimised applications and other good things.
Microsoft is also making a statement with IE9, to the effect that XP users can no longer expect to be included in major product releases. Office 2010 does support Windows XP; but you can bet that the next one will not.
The long life of XP is a side-effect of one specific thing, which is the failure (relatively speaking) of Windows Vista. I used Vista from its first release and regard it as better than its reputation suggests; but nevertheless, it was greedy for hardware resources, prone to annoying slow-downs, and less polished overall that it should have been.
There is also a real issue with application compatibility, introduced with Windows Vista, mainly thanks to User Account Control. This feature protects access to system locations such as the Windows and Progam Files folders, and parts of the Windows Registry, causing problems for some applications that expect full access.
These factors extended the life of Windows XP, resulting in the situation we have today: an operating system coming up to nine years old still in widespread use.
Very often the continuing use of XP is not something we can control. Rather, it is something we have to live with. Nevertheless, it is becoming a liability. Windows 7 improves on XP in every way that I can think of; and we even have XP Mode and Med-V to assist with migration, by running obstinate apps in virtual instances of XP.
Windows XP is something we have to live with, but no longer something to recommend.
Postscript: arriving at the gate for my flight from Las Vegas, I could not resist snapping what seemed the perfect illustration: Windows XP with a sad little error message.
I'm at the QCon conference in London, one that I particularly value for its vendor-neutrality and strong content. Yesterday we heard from Robert Martin, founder of Object Mentor, on the subject of software craftmanship, or how to avoid bad code. One of Martin's points is that having code that works is not enough. He makes an analogy with a machine. It's not enough that your car works; when you open the bonnet you want to see good engineering, not a tangle of pipes, wires and belts that somehow hangs together.
Software is vulnerable to poor craftsmanship because code is often well hidden from customers and end-users. Still, the programmer knows whether they are putting together something that just about works, or crafting something excellent that will be understandable and maintainable long into the future.
Martin's talk turned out to be a practical one. There was nothing really new; but plenty to think about. Here are a few of his tips:
You may not agree with all of these; but I like the underlying objective, which is to code to a high standard rather than just fixing bugs until it runs.
Agree? You can sign the Manifesto for Software Craftsmanship.
I've written positively about Microsoft's forthcoming Visual Studio 2010, both here and more recently in a review on The Register. I was interested to see a kind-of follow up from Jeff Vroom, making the case for doing without an IDE at all, at least some of the time:
Emacs, Vim, and other editors have basic syntax highlighting and code navigation for an even broader set of formats despite the fact that they lag behind IDEs in features. Though IDEs offer impressive plug-in capabilities, traditional script and config files seem easier to learn and use and ultimately more flexible.
Command line workflows offer a more flexible, less integrated and less guided approach to development. You learn how to use them one tool at a time. Development and adoption of new tools is usually easier as you are not tightly coupling tools into one complex user interface. Admins, analysts, and designers use command line tools, making it easier for them to work with developers when the IDE is not front and center.
I don't see a lot of designers using command-line tools; but even so I agree that there is a case for a programmer's editor with command-line compilation, rather than a huge IDE. The two things I like most about the bare metal approach are speed and transparency. Speed, because a little editor like Notepad++ starts in a blink, handles large files with ease, and does not get in your way. It is odd that performance still matters so much in an era of multi-processor machines with each core running at more then 2 GHz; but it does. Sometimes I am caught out when a monster like Adobe Dreamweaver grabs a file association for something like HTML or PHP. I double-click a document, and wait impatiently while it loads all sorts of stuff that I do not need, when I only want to make a small text edit to the code.
Transparency is an even bigger issue. If you work with simple editors and build from the command line, you are forced to be aware of what files are in your project, what tools you are using for the build, and what arguments you are passing to them. If something goes wrong, you know where to look. By contrast, IDEs hide things from you, supposedly for ease of use. In the worst case, something like a Visual Studio solution can get corrupted and leave you not knowing how to fix it, other than to create a new one and add back the files as best you can.
A similar problem comes with wizards that generate code. It is lovely to have the IDE generate all that boring data-binding code for your forms, until there is some weird bug, the results are not as expected, and you end up tracing the SQL and puzzling over why it is wrong.
Valid points; but I am still going to come down mostly on the side of the IDE. It is simple: there are so many genuinely useful tools in something like Visual Studio that productivity is better. Things I don't want to do without include IntelliSense and code completion, debugging tools with things like mouse-hover variable values and watch windows, visual design tools that generate a ton of code I don't have to write, various refactoring utilities, and build tools that save having to think about make or Ant. Visual Studio takes ages to load, but once it is up and running you can always press Shift-Alt-Enter and pretend it is a text editor.
I am still wary of wizards though; and I value knowing how to do without the IDE, even if most of the time I end up using it. As one of the comments to Vroom's piece notes, if it gets to the point where your programming skills are really IDE skills, you should worry about being so deeply tied to a single platform and way of working.