IT administration user experience

Jenni Merrifield: "It really doesn't have to be an 'Either/Or' choice between having a good GUI or a good CLI."

Indeed, it generally shouldn't be. All administrators are not the same, and they will have different working sets. What Admin A does day in day out, can rattle out command lines in his sleep and has developed a whole pile of slick scripts around his particular usage pattern, Admin B does once in a blue moon and could really do with an explanatory GUI and a friendly help system -- just the sort of things that would slow Admin A down. Conversely, Admin B's everyday tasks may be unfamiliar and scary to Admin A.

With modern component technologies, this is actually very cheap and easy to do because the actual functionality should be embedded in an object model that can be reused in thin GUIs and CLIs. We've successfully used this approach for data import/export -- our system configuration tool is a GUI, but we also have command-line tools for certain functions so we can use them in our build and test scripts. Both the GUI and CLI tools are thin wrappers over the object library where all the work happens, so the overhead cost of having two interfaces was minimal.

Jenni also notes that a CLI "should be designed with ease of use in mind" and gives as an example "parameter names should be meaningful." Hmm. One of the things CLI wizards tend to value is terseness, even at the expense of readability to the uninitiated. (Sometimes I think especially at the expense of readability.) Most CLIs nowadays seem to support both verbose and terse ways of expressing parameters or verbs e.g. Subversion's "svn checkout" or "svn co", which is a nice approach. Personally, I think the best way to achieve ease of use in an admin-oriented CLI is to standardise common options and parameters the way GUIs standardise menu names and locations -- that way Admin B can begin to transfer his expertise with CLI Tool B over to CLI Tool A and is not burdened with remembering two sets of cryptic parameters.

The vendor is not the community

Malcolm Davis, comparing C# to Java, promisingly identifies mindset as a more important difference than features. Unfortunately, he has a very bizarre idea about what the C# mindset actually is.

His sole example of the difference in mindset is that Java developers (and Java IDE providers) use Ant and JUnit -- tools initiated and maintained outside the Big Corporate world of Sun and IBM -- which he characterises as "constantly exploring opportunities for increasing productivity," whereas Microsoft are developing their own monolithic Team System to rival NAnt and NUnit.

Now if this is a difference in mindset, rather than a difference in vendor strategy, he presumably thinks all .NET programmers are sitting around in a Visual Studio-induced stupor waiting for Team System to come along -- his "accepting the tools that are provided on the desktop" mindset. I don't know which .NET shops he's investigated, but that's simply not the case. The evidence from the weblogs and mailing lists is that .NET developers have been just as aggressive about creating and using productivity tools as Java developers. The .NET community has seen what the Java community has achieved and collectively said, "I gotta get me some of that, and I'm not gotta get it now." It's the exact same mindset -- finding or making the tools no matter where they come from.

Davis may be partly right about Team System being aimed at the IT shops, as opposed to the commercial shops -- personally I think he's missed the point again, as I see Team System as a countermove to Rational in the enterprise which only incidentally sweeps up features from NUnit et al. -- but if so all he has done is identified a difference in mindset between IT and commercial development. There's nothing inherent in either .NET or Java that ties either platform to either development style, or forces their users into a particular mindset.

Modern etiquette puzzler

What is the correct form of address to use when writing to a company? "Dear Sirs" may have been acceptable back in the days of Reginald Perrin, but nowadays feels uncomfortable at best. In this case, I know that almost all the staff are women so it feels even more wrong.

N.B. as the company in question is a letting agency, I have considered "Dear Parasitical Bastards," but felt it (a) would not meet with Miss Manners' approval and (b) could result in the speedy termination of my tenancy and enforced relocation to a cardboard box on the hard shoulder of the M11.

The new music industry

Fantastic, forward-looking discussion over at the Guardian between Feargal Sharkey and Jem Finer of how music and the music industry can move forward in the Internet environment. Realistic about the dangers, excited about the opportunities, and very much focused on working musicians.

Haere ra, Blighty

I've had my "expression of interest" in emigrating to New Zealand selected by the NZ Immigration Service.

This does not in itself entitle me to live in New Zealand. What it means is that once they have verified my details they will invite me to lodge a permanent residence application. I can't actually gain permanent residence until I have a job there, but once I do have a job offer, I should be able to obtain residence pretty quickly. I'll be flying out in January of next year and taking a couple of months' holiday with the Kiwis before starting the job search in March.

From the people I've talked to about my decision to emigrate, I'm not the only one wanting to leave the UK, so I'll try to record my experiences here for what it's worth, in case anyone else finds them useful.

I am what the Americans would call "super excited" about this. I have to admit, though, I am also "super scared witless" about it and "super turned off" by all the tedious paperwork and logistics involved in shutting down my life here and restarting the important bits in New Zealand. It's going to be a big break, there's going to be a lot of crap, and I know there's no guarantee it will work out. No matter. It's worth the try.

Ka ao, ka ao, ka awatea.

The five laws of prototypes, minus four

Tim Weaver: "Here are my five laws of prototypes that I've found to be universally true."

Very far from universal, Tim. All of the laws except the first essentially say, "The prototype will become the production system." This may be universally true in Tim's experience, but for me it's actually true only in a minority of cases. Perhaps I've been lucky. Perhaps Tim's been unlucky.

The first prototype I worked on was some seven years ago -- my then company's first major Windows product, and first MFC project. We did a quick prototype to learn MFC, to get the user interface agreed, and to have something to demonstrate at trade shows. It was a horrific piece of code, full of abandoned experiments and performance-murdering simplifications. (By the time it was completed it took minutes to start up.) We threw it away and thanked providence for the lessons learned. If we had carried forward any of the poor coding practices or made the performance worse, in accordance with Tim's laws 2 and 3, we wouldn't have had a product. If we hadn't done the prototype at all, we would have made all those disastrous mistakes on the production codebase, and then it would have been really hard to excise them.

Another salutary example came at my next company, where I was asked to prototype a user interface for a significantly more complex feature than we had before. Again the prototyping was done using MFC and again it was full of hideous hacks. If I remember rightly, the view class got so mangled that I ended up #defining the MFC document type to point to a member function of the view -- truly unspeakable stuff. Did the production developers obey law 2 and replicate my poor coding practices? I think not. Did the prototype obey law 4 and live forever? No, it died as soon as the production code reached UI scaffolding. Did the production developers obey law 5 and reuse my snazzy timeline control? Possibly, but then it was actually a good fit, because I'd had to throw away the "easy" option because it didn't implement the behaviour I needed. I'm pretty sure they didn't reuse my other controls! I had a similar experience on a smaller Web-based prototype -- the original wasn't so bad this time, but we still started over when we came to do the real thing.

Finally, an example of prototyping at White Carbon. About 18 months ago I prototyped a Gantt chart style planning UI. Performance was poor and the code was deeply confusing. Later I was asked to prototype a Gantt chart UI for historical views of activity within a lab. This time around, I obeyed all of Tim's laws, lifting cryptic code wholesale from the earlier prototype and kludging it into working. Why? Because this was just another prototype. It didn't deserve care and attention. I later came to develop the production UI, and the lessons I'd learned about flicker, speed and code structure meant that I was able to product a component I'm pretty pleased with in terms of usability, clarity, functionality, aesthetics and maintainability. We simply junked that hateful prototype and every line of code that was in it: laws 2, 3, 4 and 5 didn't apply.

So while Tim's laws of prototypes may well reflect one experience, they're very far from universal. Indeed in my experience they represent the minority of cases.

So do take Tim's laws as well-tested warnings of common mistakes that must be avoided, but don't believe that they're inevitable. Don't fall into the trap of refusing to prototype because you think the prototype is bound to taint the production code: honestly, it's better to make your worst mistakes quickly and where you can throw them away. But it is up to you to be strong, to make sure that you don't become a victim of Tim's laws. Make it very clear that the prototype cannot go forward. Make the prototype so bad that it can't go forward. Make sure that you have sufficient influence on the project that you can ensure that your prototype's bad coding practices don't get picked up.

Tim's laws are a great way to summarise the dangerous pressures that a prototype puts on production code. But they don't need to be true. And if they do come true on your project, you may have only yourself to blame.