Agents for Software Engineers

What do glamorous movie stars, rock stars, professional sports players, and software engineers have in common? "Nothing" might be the first answer that comes into your head. After all sports people and movie stars are the modern heroes, the cool people that kids aspire to be when they grow up. Software engineers have a Dilbert like reputation for being geeks. So why compare them?

Well they have a number of things in common.

Firstly there is a huge range of talent and a huge differential for hiring the best. If you hire an A-list actor or actress it will boost the box-office returns of your movie. If you hire the best soccer player in the world, not only will it boost your teams results on the field far more than buying two medium level players, but also the merchandising potential. Similarly, anecdotal evidence as well as studies suggest that hiring one great software engineer is far better value than hiring two good ones.

Secondly the best can become very rich. Some Microsoft programmers are among the richest people in the world.

Thirdly, job decisions tend not to be made just by money. For Rock stars it might be the fruit and flowers in the dressing room, or some claim to artistic independence. For movie stars, it might be the opportunity to work on a script which might win them an Oscar, or stops them being typecast. For programmers it might be a nice office, cool chairs, or toys to play with.

Fourthly for all four groups, their talent does not necessarily lie in business or negotiating skills. Rock stars and actors are notorious for being arrogant, demanding and hard to work with. Programmers are renowned for having bad people skills.

All of which leads me to something that has puzzled me for a while - why don't programmers have agents? If an actor is considering a role or a rock star is considering a record deal they have an agent who sits in the middle, helps them negotiate the best fee, and takes part of the money as a cut. The star doesn't have the stress of negotiating (and the producers can avoid some of the stress of negotiating with actors) and hopefully the star gets better compensation.

If superstar programmers are really worth five times as much as mediocre ones, why aren't they getting agents to negotiate larger salaries for them? I'm sure there is a business opportunity here. This differs from the standard recruitment consultant. A recruitment consultant tries to fulfill the role, but differs in the major respect that there is no expectation of a long term relationship between the consultant and the programmer. Once a job is found, the relationship typically ends.

I'd guess one reason for the lack of agents is that lack of talent or relative talent is much harder to judge quickly in a programmer than in an actor. Programmers don't usually work in the public eye, so it is harder for talent to be spotted by agents on the outside.

Traditionally programming has been considered a full-time occupation whereas actors, sports stars and rock stars tend to be on much shorter contracts. However, with the growth in consulting, outsourcing, and shorter term contracts this may be becoming less true.

Also to consider is the role of the IT consulting company. When you put together a sports team, you don't go to a baseball consultant and get all the players from one source. However in IT projects, it is common to hire more than one person at once and try and get the best quality team you can. The IT consulting organization plays the role of the agent, and takes the money. This is yet another byproduct of the programmer's name not being on the product in the public eye, rather the brand is the organization the programmer worked for.

Finally worth mentioning is that whenever the phrase software agents is used, people think of the over-hyped AI definition.

I don't know if programmers will ever be saying "Have your people call my people," but it remains for me an intriguing image.

A Little Security Protocol puzzle

As Bruce Schneier is always talking about, sometimes real world security protocols are far more flawed and hackable than computer ones. Sometimes they are plain badly designed. And sometimes they are well designed, but reveal more about a companies priorities than they intend to.

Before I went on holiday, I went to get some Swiss Francs from Travelex. When the lady behind the counter asked me how I'd like to pay, I said through debit card. She then told me I would need photographic id, which was a pain, because I didn't have any on me. She then told me that if I wanted to pay in cash, then she wouldn't need ID.

So I didn't use my debit card in Travelex, and type in my PIN there (the UK now uses Chip and PIN rather than signatures to authenticate purchases). Instead, I walked 400m to an ATM, used the same Debit card and same PIN to take out £100, walked back to Travelex with the £100, and then used the cash to get some £100 worth of Swiss francs.

So the puzzle is this - given that I would have used the same card and same PIN in both situations, what possible reason was there for Travelex to be happy with doing this second method without ID, but not the first? Read on for my suspected answer, or think about it yourself for a minute...

SPOILER BELOW

I think there was no added security, just an exchange of risk. Consider if it had been a stolen card and PIN. If I had just used the card at Travelex they would have taken some liability. By forcing me to walk to the ATM, if the card had been stolen, the ATM would have taken some liability. In order to take this risk of liability, they require photographic ID to reduce their risk. So instead, they gave me the risk of walking through the streets of London with a lot of cash. As a result, the transaction was far more anonymous, and so more vulnerable to money laundering, and I was at more risk of being mugged, but neither of those hurts Travelex.

Of course, this is very sensible of them. The best solution is for me to carry photo ID.

Writing is like UI design

Writing documents is just another form of user interface design. Especially if those documents are examples or tutorials. That might be a bit of a geeky way of looking at the world but I think it is true.

I was reading this post from Jensen Harris on how difficult it is get users to criticise user interfaces. He calls it "Usability Stockholm Syndrome". Meanwhile, from his body language I could tell one of my co-workers was obviously not that happy with a document I had written on recovering if one of our systems has an error. However, I found it really hard to get him to tell me what could be improved about it. He kept saying "No it's fine." Or "It's adequate." I had to really emphasise I want to improve both my document and my writing abilities to get some useful feedback.

This reminded me of reading a great book on writing software manuals - the User Manual Manual by Michael Bremer, who also wrote Untechnical Writing. In it he looks a trying to document a user interface. Unfortunately accomplishing the simplest task requires paragraphs of difficult prose, operating 200 different GUI controls. He says it's often much better to fix the user interface so performing the task is easy, then writing the documentation will just be an easy to understand paragraph.

There are other similarities between writing and developing user interfaces:

• The end users don't always know how to improve them, but they know when they find them difficult to read or use
• Important elements have to come to hand quickly, more obscure details can be left until later or put somewhere more obscure
• Eat your own dogfood is necessary for quality but not sufficient
• Hallway usability tests work for both

There are probably a lot more, but these are the first few that come to mind. I'm not sure what benefit realising this similarity brings to the world, but when I look at articles about writing or user interface design in the future, I might try and transfer the ideas. After all, the best innovation comes from stealing ideas from other fields and applying them in a novel way.