« April 2005 | Main | June 2005 »

May 30, 2005

User experience and the development team

Matt Goddard, the man Don Norman turns to instead of Jakob Nielsen when he needs his Web site usability improving, expands on Alan Cooper's adage that "user interface is not just skin deep."

The problem with Matt's remarks is that he is dealing with API usability within the development team, and this is neither necessary nor sufficient to guarantee a good user experience for people outside the development team. API usability is a good thing, of course, and who could argue with guidelines like "Your objects should be named clearly" -- but the goals and concerns of the developers are different from those of the end users. It's very important to developers that your lookup table class is called Hashtable or Dictionary rather than GemmasCoolClass, but it makes no difference to the user experience whatsoever (except of course in terms of delayed delivery and slow maintenance).

Where Matt may have a point is in the idea of treating API usability as a training ground for real user experience. If developers can learn to plan their APIs around their usability to the rest of the team, that may train them to plan their user-affecting designs around their usability to real people. On the other hand, it may just train them to expose the usual implementation concepts with blindingly precise technical jargon instead of the usual fuzzy sugar coating. ("Well, maybe they shouldn't employ nurses who don't know what a red-black tree is!")

API design does have a part to play in the usability process, but it is as part of the top-down design of the system, for example the design of domain objects to support the desired user experience -- a design that can then feed down into the design of implementation objects and data stores. What Matt is writing about is the simple fundamental of keeping the development team productive and sane, a concern which is actually pretty much internal to the development team.

Heh. Actually, I recognise this whole symptom of starting to care about the development team's sanity and health rather than regarding them as a necessary but expendable labour force to be subjugated to your will no matter what the cost. Watch out, Matt. I think you may be going native.

May 30, 2005 in Usability | Permalink | Comments (1) | TrackBack

Declarative programming and debugging

Declarative programming -- from regexes to XAML to mega-configuration like WSE or Enterprise Library -- can be pretty sweet, but my goodness, it's awful to debug. Get something wrong and it just doesn't work, or goes completely bonkers: we don't seem to have the tools to localise problems.

I don't have a solution; in fact I don't even have an idea of what a solution would look like. By the very nature of declarative programming, conventional ideas such as breakpoints and tracing are hard to apply. But there are increasingly complex declarative languages out there and it would be nice to have some way to track down errors more easily.

May 30, 2005 in Software | Permalink | Comments (0) | TrackBack

May 23, 2005

Structured blogging

Scoble: "The idea is to make a movie review look different from a calendar entry."

This is a misleading way of putting it. To human readers, movie reviews might still look like book reviews, calendar entries, Flash games about fighting bananas or any other kind of Web page. What is useful is to provide internal structure and metadata that allows programs to organise the reviews more effectively. Enabling programs to break down a movie review into (say) title, cast and body content enables new, movie-centric applications, just as RSS' enabling programs to break down a Web page into stories enabled aggregation, syndication, etc.

What I'm interested in is less new presentation than new navigation. I want to post book reviews to my site and have them navigable by author and title, rather than by date. (So instead of seeing a calendar over on the right, you'd see maybe a couple of A-Z grids, which would take you to "all authors beginning with A." Or something.) I want the author's name to be a link that takes you to all my other reviews of books by the same author. I'd like to be able to make a link which takes you, via Technorati or the like, to a list of other reviews of the same book. Oh, and of course I want to make it easy for you to buy the book, unless it's The Da Vinci Code of course.

By the way, TypePad's TypeLists are a primitive implementation of this kind of feature. As well as some possibilities (such as linkage to Amazon), they show up some of the difficulties in the whole idea. Do I really have to provide a star rating for everything I review? What if the metadata authorities decide that a book review must specify genre, a concept I loathe, despise and will have no truck with? How much flexibility can we offer authors before the schema becomes so general as to be useless? (In the current draft, the simple-review schema makes everything optional except the title of the review. Consumers can't even rely on finding the name of the book or movie being reviewed. Conversely, there's no optional field for series or hero, so I can't subscribe to "all reviews of Stephanie Plum books.")

Now, none of these questions are new. The SGML folks have been battling with them for decades and have won limited victories such as Dublin Core. I was unable to find any reference to such efforts on the structuredblogging.org site, which I found rather alarming. I'm not proposing DCMI or OASIS or whoever as an arbiter of structured blogging standards -- they're too slow-moving and too centralised for the weblog world. But these are smart people confronting similar questions and trade-offs to the structured blogging issue, albeit in a different environment: you gotta think we could learn a great deal from their experiences (both positive and negative) and decisions.

Structured blogging is a tough problem, especially given the decentralised and fiercely independent nature of webloggers and communities. But it opens up a world of exciting applications based around tailored, fine-grained metadata, just as we already have a range of applications based around the coarse-grained metadata of RSS. It's a problem well worth cracking.

May 23, 2005 in Web | Permalink | Comments (1) | TrackBack

I love America

I ordered some CDs from the US recently and many of them came with a Dreadful Warning from no less an agency than the FBI:

FBI Anti-Piracy Warning: Unauthorised copying is punishable under federal law, plus official-looking FBI logo

Gotta love a country where CDs merit a Dreadful Warning but guns don't.

May 23, 2005 in Web | Permalink | Comments (3) | TrackBack

May 22, 2005

Another peripherals story

Those who have shared my troubles with uppity peripherals might be interested to hear about my experience with bliink ADSL.

Total installation steps required: Plug computer into wall*. I accept that this step was pretty much unavoidable, though Woosh seem eager to invalidate that particular assumption.

Total user interface displayed: A tooltip saying "A LAN cable is plugged in." And since then, even the little blinkenlight icon has gone back to politely hiding itself.

Total amount of post-installation fiddling: None. It didn't even ask me for logon information: bliink preconfigure the router with the right username and password before shipping it.

In my comments on Vodafone's equivalent offering for GPRS, I quoted Alan Cooper's great maxim: "No matter how cool your user interface is, less of it would be cooler." By this measure, bliink's UI is so cool that even polar bears will be reaching for their woolly jumpers.

If only all software were like this**.

* Actually, I being a little ingenuous here. I actually had to plug the computer into the router, the router into the filter and the filter into the wall. However, since there was only one way in which the cables and sockets could physically fit together, this was still about as easy as any installation can be where hardware is involved.

** Well, maybe not exactly like this. I appreciate that a hidden blinkenlight might not be the correct user interface for an industrial-strength word processor.

May 22, 2005 in Usability | Permalink | Comments (0) | TrackBack

The simplicity backlash

BBC News: "Vodafone is launching a back-to-basics mobile phone in response to customer demand for simplicity."

May 22, 2005 in Usability | Permalink | Comments (0) | TrackBack

Lie detectors for plants, and other wonders

Arty Bee's Cabinet of Curious Bibliophilia, brilliantly, opens its review of How to Build a Lie Detector, Brain Wave Monitor and Other Secret Parapsychological Electronics Projects with "Actually a very interesting read, if you're into this kind of thing." Uh, right. Hands up everybody who is "into" building lie detectors... for plants. Even more brilliant is the picture of "a depressed philodendron after receiving excessive threatening."

Other high points: The History of Lesbian Hair, Secrets of Fascinating Womanhood ("Actually the first woman looks like an old boyfriend if you add a beard and moustache"), The Message Given to Me By Extra-Terrestrials ("We have decided to take the path of tolerance and let the cover speak for itself. Except that the man has a truly bodacious comb-over. And obviously he's completely nuts.") and actually the whole site.

(Note: the site is framed so the link takes you to the Arty Bees' home page. Sorry, I couldn't link to the Cabinet itself without losing the site navigation.)

May 22, 2005 in Books | Permalink | Comments (0) | TrackBack

May 10, 2005

The parable of the managers

And it came to pass that there arose two software managers in the land of the Wellington-ites.

And the manager Ahimelech and the manager Balazar did meet, even at a sushi bar, and did contend mightily in faith. For both purported to follow the way of the profits, but could not agree how best to follow the teachings. And they agreed to go forth, and to tend their vineyards, and to meet again on this day to see who wouldst be the victor.

And in that year the manager Ahimelech had one servant, and the manager Balazar one servant likewise.

And Ahimelech said unto his servant, "Go thou quickly and set thyself to toil in the codebase, forgetting all else. For we must maximise our chargeable hours, and have not the time or leisure to waste on that which does not profit us. For we could spend even unto half our lives writing the tests of unit or setting up the build of nightliness, and for this the customer payeth not."

And Balazar said unto his servant, "Go thou likewise and toil in the codebase, but before thou goest, write thou thine documents of design and set up thy server of continuous integration, and as thou goest, do not fear to tarry by the roadside and write thy comments of documentation."

And the servants went forth, and the year did pass.

And Ahimelech and Balazar did meet and did exchange company confidential financial information, for despite being managers they were also of the tribe that is called Software. And Ahimelech had realised a profit of a hundred shekels, and Balazar only fifty.

And Ahimelech did patronise Balazar mightily, even unto putting a hand onto his shoulder and saying, "Thou seest, friend, thy servants wasteth half of their time on the tests of unit and the builds of nightliness, while my servants bury their heads in honest toil. Heed thou my words, for I am commercially focused, and despise the ways of the heathen."

But the manager Balazar would not relent, and did say, "If my servants spendeth half their lives on the hygiene of source control and the tracking of bugs, yea my heart rejoices, for such I believe to be the way of the profits, and though the CFO sendeth great memos against me and the customer waxeth sore wrath against my timescales, I remain steadfast in my faith."

And Ahimelech and Balazar did agree to meet again.

And in the next year Ahimelech had two servants, and Balazar two servants likewise, and both gave their servants the same orders and sent them forth to toil in the codebase.

But the servants of Ahimelech, mightily though they strove, failed to obey their master, for the new servant did trouble the old servant mightily, saying, "How worketh the module of logging?" and "Why buildeth not the adapter of database?" And the old servant replied, "Go read the documents of design, though I warneth thee that they may be aged and feeble, and thou must read the code to be sure, for I had not the time to keep them in sync with the code; and by the way, be thou aware that some of the paths in the code are obsolete, but I had not the time to clean them up," and "It buildeth upon my machine, go forth and figure it out for thyself, for I must toil to keep my chargeable hours up." And the new servant went forth and did figure it out, and did toil in the codebase, but when his changes were deployed, lo, they broke the existing code in obscure ways, and both servants had to toil mightily to find and fix the problem.

But the new servant of Balazar did not trouble the old servant, for all he wished to know, he found in the web of wiki and the comments of documentation and the tests of unit. And when he trampled on the codebase, the tests of unit did send a red bar to warn him away from sin; and he laid on hands and did heal the problem even before he performed the check of in.

And so it came to pass that Ahimelech and Balazar met again and did again exchange confidential financial details. And the company of Ahimelech had profited by one hundred and fifty shekels, and that of Balazar by one hundred shekels. And Ahimelech, though his heart rejoiced not at the decline in per-developer profits, did again gloat, saying, "See, thy tests of unit and builds of nightliness avail thee not; the profits bless my enterprise. For my servants toil full-time in the codebase, well, almost full time, while thine tillest for much of the day the profitless soil of the Best Practices."

And Ahimelech and Balazar did agree to meet again.

And in the next year Ahimelech had four servants, and Balazar four servants likewise, and both gave their servants the same orders and sent them forth to toil in the codebase.

And the new servants of Ahimelech did trouble the two old servants mightily, and both of them promised to send the new servants the documents of design and the instructions of build, for they were not to be found on the network, but only in their local C:\DOCUMENTS folders (for the old servants trucked not with the sissy "My Documents" folder, yea even though the sagacious IT group had mapped it to a network drive where it would be placed on the tape of backup). But under pressure of a customer delivery they forgot, and the new servants had to reverse-engineer the design from the code, and figure out the process of build on his own. And these activities so delayed them that the delivery date slipped by two months, and the customer was much vexed, saying, "At what playest thou, you said the end of February for certain, and now thou takest twice as long; and I say unto you, I am not bloody paying any more, thou canst do it for the price thou quoted." And the oldest servant quarrelled with the middle servant, complaining that his design supported not a scenario that the oldest servant knew of, but had written not, and did spend many weeks rewriting the middle servant's code. And the Lord sent a head crash to punish the oldest servant for his rudeness, and he did lose even unto six weeks of work, for he practised not the hygiene of the source control. And the newest servants, like he who had gone before, did again trample on the delicate codebase, but left footprints so light that they did not come to light until the system had been in production for a week, after which it crashed like a Volvo upon the motorway, and stayed down for two days; and the customer waxed sore wrath, saying unto Ahimelech, "Lo, thy servant has cost me a thousand shekels, and I invoke the clause of penalty."

But the new servants of Balazar troubled not the older servants, but instead placed their trust in the web of wiki and the documents of design and the server of build and the tests of unit and the bar of green. And though the Lord sent a thief in the night to nick the oldest servant's laptop while he waited for the train of mainline, it impacted the project little, for due to the hygiene of source control, only a few hours of toil were lost. And though the Lord insinuated a bug into the new servants' code, the tests of unit and the bar of red did smite it before it could reach production; and the customer looked upon the availability ratings, and rejoiced, and did renew the contract of maintenance.

And so it came to pass that Ahimelech and Balazar met again, and the company of Ahimelech had profited by one hundred and eighty-seven and a half shekels, and that of Balazar by two hundred shekels. And Ahimelech did wax sore defensive, saying unto Balazar, "Lo, perhaps we had a bit of bad luck this year. But my servants toil one hundred percent in the codebase, while thine spend half of their time drinking and making merry at the tavern of the Best Practices. Things will be different next year."

And Ahimelech and Balazar did agree to meet again.

And in the next year Ahimelech had eight servants, and Balazar eight servants likewise, and both gave their servants the same orders and sent them forth to toil in the codebase.

And, to cut a long story short, the servants of Ahimelech spent an exponentially decreasing amount of their time toiling, and the rest of their time arguing, explaining, fixing, firefighting, figuring out and generally not toiling; while the servants of Balazar spent a constant 50% of their time toiling, and a constant 50% on the tests of unit and the hygiene of source control and the web of wiki and, in general, drinking and making merry in the tavern of the Best Practices.

And, yea, even unto this day, the manager Ahimelech sayeth unto his servants, "Toil ye harder, and be not tempted astray; for those who tarry with the tests of unit and the builds of nightliness and the hygiene of source control and the web of wiki do sacrifice their chargeable hours willy-nilly. Like fools they give up their time, so this year for sure the profits will be ours." And for ten years, and twenty, and thirty, he hath been saying this. And ye who wish thy businesses to scale, do thou the sums and follow the true path of the profits.

-- Book of Profits, with apologies to Verity Stob. And to God, of course, but mostly to Verity.

May 10, 2005 in Software | Permalink | Comments (4) | TrackBack

May 08, 2005

Looking for work in New Zealand

TimB reminds me that I have been awfully dilatory about posting on my NZ migration experiences. Many apologies. I've been jotting down notes, both on the general migration process and the specific experience of job hunting in the software development field, but not got around to posting them. Hope this is useful, Tim.

My experience is that the NZ IT job market is extremely buoyant at the moment. I started looking for work in mid-February: within two weeks, I had my first offer, and another week after that, I had three more.

You can therefore usually ignore the big warnings on many job adverts which say, "Only people legally entitled to work in NZ may apply for this job." I panicked a bit when I saw how many jobs seemed to rule me out in this way. It turns out, however, that this is only intended to discourage dilettante types who haven't considered what's involved in migration and merely think NZ might be amusing this week. If you're in country, and you don't have to go back to settle your affairs, and you can persuade them that you're committed to immigrating (the phrase "My permanent residence application went in on Friday" works really well here), most employers will forget that clause as quickly as you can say "Priority Occupations List."

In fact, if the advert doesn't say "Only people legally entitled to work in NZ," then feel free to apply from out of country. One of my colleagues got his job by phone, and was therefore able to get a work permit before entering the country, and I've heard of UK nurses and teachers getting offers the same way.

Be warned that just being in country is not enough. Employers are aware of the "LSD trip" -- Look, See, Decide -- where someone turns up thinking NZ might be fun, gets a job to see whether it is, and then bails after a few months when they decide it's not. You need to demonstrate more commitment than just a return ticket. Expect to get asked "Why do you want to come to New Zealand?" at every interview. Try to work a derogatory remark about Australians into your answer: it will prove you have bought into the mainstay of Kiwi culture.

Once you get a job, expect the employer to be keen for you to start asap. It will depend on the employer, but do not plan to land your job offer and then take your holiday. If you want to see the country before starting work, enter as a visitor, go sightseeing first, and then start looking for work.

I realise these are contradictory messages. Some employers are so keen they will offer you jobs from the other side of the world; others will be deeply dubious unless all four grandparents were native-born Kiwis. So it goes. Kiwi companies are small, and individuals' personal experiences count for a lot. If a manager or HR bod has had one bad experience with a LSD immigrant, they may be prejudiced against all immigrants; if not, they may be so keen to get the talent in that they'll take even speculative enquiries. I've been told that looking for work while being in country is the "sweet spot," and it worked well for me, but obviously I haven't tried any other routes!

Some other observations:

* Because travel in NZ is slow, applying for jobs away from your current location is more painful than in the UK. Travel times between the main centres (Auckland, Wellington and Christchurch) mean air travel is the only option -- Auckland to Wellington by car is a full day -- and that is a barrier for some employers. You'll have to live somewhere while looking, and wherever you happen to choose will affect who is willing to talk to you.

* From my experience, although most companies and jobs are in Auckland, Wellington companies are more responsive. If your focus is on finding and starting work quickly, you may want to base yourself near Wellington rather than near Auckland. However, many companies have branches in both cities and will happily do preliminary interviews at the 'other' location. In fact for the job I accepted I interviewed only in the 'other' location and spoke to my future boss only by phone.

* Kiwi companies regard culture and getting on with people as very important. (Sometimes they take this to extremes. One interview process I went through involved only one technical question; the rest of it was entirely cultural, and consisted primarily of them relating incidents of transvestitism in the office. Remarkably, they felt they'd got enough from this to make me an offer.) Almost every company will ask you to give an example of an interpersonal conflict and how you resolved it. So if you haven't got a fight with a co-worker under your belt, go off and have one quick.

* Kiwi companies will require, and take up, technical references. I was asked not just for my provided 'human resources' type references but also for a colleague who had worked with me, and someone who had worked for me during my management era. (Royston and Matt, thank you for your patience: I owe you both beers next time I'm in the UK.)

* If you want to get out of the big cities, you can do, but do think ahead. The reduced salaries (by 30%+, compared to Auckland and Wellington) are not necessarily an issue -- nobody comes to NZ for the money -- but (a) in popular centres like Queenstown, salaries may be down compared to the cities but living costs may be up; and (b) smaller towns will rarely support multiple IT employers, so if the job doesn't work out, or when you outgrow it, you will probably have to move to find something new. A friend also warns that, when you move on, you may encounter the question, 'If you're so smart, why did you have to go to Stewart Island to find a job?' The obvious response to this is to leap across the desk, smash your interviewer's face into his desk and yell, 'It's all about lifestyle, you clod!" But I haven't really tested whether interviewers find this a convincing response.

* Related to the LSD issue, I was told that I would find employers more responsive if I had a NZ email address. I don't think this made any difference, as my normal email address is not recognisably country-specific, and I was able to give a NZ postal address as well, but it's probably not a great idea to present UK addresses for both postal and electronic mail. Apart from the usual generic email providers, you can get a free NZ address from Orcon, including free POP3 access.

* If you come to NZ without a job in hand, don't plan to job-hunt any time from mid-December to mid-February. Because Christmas/New Year coincides with the summer holidays in this hemisphere, companies tend not to be interested during this period. (I'm passing on advice here, and can't confirm it from personal experience. For example, I received one warning that things might stay tough right through till May, when budgets had been finalised, but for me that worry never materialised.)

Final cautionary note: at the time of writing, according to local news, the economic mood is becoming pessimistic. At the moment, things are good, but an increasing number of employers are doubtful about prospects for the near future. I suspect this primarily reflects the manufacturing and agricultural industries, and that the technology sector will remain an employee's market, but no warranties express or implied, etc. I know my company, for one, is still recruiting like a thing possessed.


Best NZ IT job site: Seek. By such a distance that there's no point mentioning any others.

IT recruitment agencies from whom I got good results:
* Alliance IT
* Enterprise IT
* Absolute IT

May 8, 2005 in UK-NZ Migration | Permalink | Comments (4) | TrackBack