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:

• Keep functions and methods short. How short? His principle is to use extract method refactoring until there is nothing more to extract. I got the feeling that he would consider anything over 20 lines suspect.
• Have functions with only a few arguments - preferably no more than two - and don't use boolean arguments because they cause confusion.
• Similarly, a class should be a small batch of code, with only a few variables, a couple of dozen methods.
• Eliminate duplication in your code; use abstraction.
• Give public methods short names, but use long descriptive names for private methods. The code is the documentation.
• Improve code slightly every time you touch it. Sometimes the opposite happens; code decays as fixes get added. If you improve it instead, your project improves over time.
• You need comprehensive tests, otherwise you do not dare to make changes in case something breaks. Test code should be of the same quality as production code; if your tests are slow and buggy, you will not use them or trust them.
• Have short iterations. A month may be too long. Two weeks is good. One week, he suggests, may be ideal; or even less in some cases.

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.

As I teach and coach project managers, I'm struck by how many are stuck in command-and-control thinking: I must monitor all the work. I must check in with people to see that they are doing their jobs. I must know all the technical details and make technical decisions about the project. I'm sure there's more.

But that's not the role of the project manager. Nope. The project manager exists to create the path for the project team members to succeed. The way a project manager does that is:

• Select a lifecycle that manages the project's primary risks
• Help the sponsors define what success means
• Help everyone define release criteria
  
• To be aware of and manage all kinds of risks. If those risks are technical and the pm has the capability to manage those risks, then the PM can make those decisions. But it's more likely the PM has to make sure someone on the team can make those technical decisions.
• Protect the team's process from outside influence. If the team wants to improve or change their process, great. If someone from the outside wants to impose something on the team, the PM has to protect the team.
• Allow the team to do the technical work and the pm does the rest-of-the-organization interfacing work
• Help the team see when they are making progress and when they are stuck.
  

Now, there are plenty of things the project the PM needs to do around progress:

1. I like helping people define their inch-pebbles. In the case of an agile team, making sure the stories are sufficiently small. I often discover the team members don't know how to make their work units small enough to see progress.
2. Notice when the team's process is not helping them make progress. For example, a long build time or lack of continuous integration can impede a team's progress. If you're the one enmeshed in the situation ("I have to wait for the build to finish" or "I have to wait for John to check in his changes") you may not realize you are not making progress. In that case, the pm needs to put a structure in place to make those problems obvious. On a non-agile project, I do this with one-on-ones. In an agile project, I do this standup meetings.
3. Make sure everyone knows what is most important to work on now and next. I like ranked backlogs, no matter what kind of lifecycle you use on a project.

So, a PM doesn't need to be the center of the project and control everything. The PM can let the team be the center, and facilitate the team's work.

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.