An Incentive to Lie

If there is one thing I really hate it is when a company creates a situation where lying to them makes everyones life easier, and hurts no one.

As a Christian, I try not to lie, even with "white lies", mostly because of these passages in the Bible: Matthew 5:37, James 5:12, and various false witness verses. So as someone who tries to live honestly, it is very annoying when my life would be so much easier if I lied, for no good reason. I've come across two examples recently, but they seem to happen fairly regularly to me, so I'm sure I'll notice more.

The first is the fault of the DVLA (Driver and Vehicle Licensing Agency). In England we have two parts to our driving licenses, a plastic credit card sized identity part, and a paper record part. This is a fairly silly design to start with, but let us ignore that for now. I recently lost (or had stolen) my wallet and in my wallet was the plastic part of the drivers license. I keep it there because it is a useful photographic ID with proof of age. I do not carry the paper part about because it is more bulky.

It is a legal requirement to be able to produce your driving license, so I need to get a replacement. Now according to their website, if I had lost, or had stolen both parts I could just call up, pay the fee on my credit card, and get a replacement sent to me. But because I have only lost one part, I have to fill in a form, and post off the paper part back to them. So it is in my interest to lie and say I've lost both bits which saves me some hassle and doesn't hurt them. But if I'm honest my life is made harder for no good reason.

A second example was similar from First trains. My train season ticket wore out - it stopped working in the barriers at the station. If I was dishonest I could ring up, say it had been stolen, and get a replacement sent to me. But if I was honest I had to post them the ticket, wait for them to post me a replacement. While waiting I had to pay for daily tickets with my own money, save the receipts, and then post them all off to get a refund. A lot of work, for no real benefit, as if I wanted to cheat them, I could just lie and say it was stolen.

Companies shouldn't be encouraging people to be dishonest to them.

Being User-Focused: More examples

Royal Mail's feedback options just provide more examples of them not being user focused, but Abel & Cole get it right.

On Friday I was ranting a bit about how the redelivery service for Royal Mail's recorded delivery demonstrated a lack of user focus. I decided to try and be helpful, and send a copy of my comments to the Royal Mail. That is when I discovered the horror that is trying to give online feedback to the Royal Mail.

Before I start criticising, let me add some mitigating comments. The number one priority for the Royal Mail has to be getting as many deliveries as possible to arrive, safely, and on time. Any other customer service issues will always be secondary to that, and if all of their energy is currently devoted to sorting out delivery problems then that is entirely reasonable.

However, suppose you are a customer, who, like me, wanted to make a suggestion on improving their redelivery options, or make some other suggestion about Royal Mail service. So much about the process is horrible I cannot describe it, you have to experience it for yourself. The only reason I can think of is that they are trying to persuade you that writing letters is better than email! But in summary:

• There is no contact email address
• You can only give feedback on the website, not on anything else
• You have to log in before giving feedback!
• Before giving feedback, you don't merely relinquish any intellectual property claims to the idea, you assign all intellectual property to the royal mail
• Feedback is limited to 255 characters at a time
• You are limited in the number of pieces of feedback you can give, and you have to work through a horrible, slow customer service wizard
• As part of the process you are shown everyone else's rude comments about Royal Mail

The process is so bad it is almost funny. It leaves Royal Mail's customer service department looking like a shambles. Feedback should be sought out, not made as hard as possible to get.

Abel & Cole

In contrast, Abel & Cole are incredibly user focused, and as a result I have recommended them to a huge number of my friends, and I recommend them to you all. They deliver boxes of organic fruit and vegetables, either irregularly or regularly. I have no interest in Abel & Cole besides being a satisfied customer.

I cannot list all the things they do well, as there are probably many I have not discovered. However, a few highlights are:

• You can contact them by email, telephone, fax or letter, with clearly presented addresses on a contact page. They explain clearly when the office is open, and what you can do if it is not
• When you set up your account, not only do you give a delivery address, there is space for extra directions for the delivery man, and instructions on where to leave deliveries if you are out
• When my wallet was stolen, I let them know, and they responded promptly, by telephone, to my daytime number as it was daytime, and said they were happy to delay the charge and keep delivering until I could register my new card with them.
• They will deliver weekly, monthly, biweekly, or on irregular intervals or one-off orders
• They provide recipes and descriptions for items you might not know what to do with
• They allow you to list items as disliked, and they will never deliver them to you again

Each of these clearly solves a specific problem that someone has had or could have had in a nice way that it easy for the user. As a result, it is easy for me to spend money with them regularly every week, and so I do, and we are both happy.

Not User-focused: An Example from the Royal Mail

What happens when you are not at home for a delivery provides a good non-programming example about what it means not to be user focused.

One day soon I'll write and article on being user-focused, which is something that a few programmers and software companies do really well, and as a result they do well, and a lot of programmers do badly. However, this week I came across a really good non-programming example which I thought I'd share.

There are three classic symptoms of not being user focused:

1. It is possible to get the job done.
2. The way that would make it simplest for the user to get the job done does not happen, and often the user is made to feel stupid or awkward for wanting it done this way.
3. The job is done in a manner which seems most convenient for the people doing the job.

I think this story illustrates all three.

The other day I ordered a firewire card for my laptop, as the built in one has died. Normally I get parcels delivered to work, but the udiggit would only deliver to the credit card address, so I had to get it sent to my home. Unfortunately, they sent it Royal Mail Recorded Delivery.

A brief aside for those of you not in the UK. The Royal Mail are the UK's postal service. Recorded Delivery means it normally arrives within 24 hours and has to be signed for. And this is where the problems start.

I am usually at work during weekdays, so I am not at home to sign for items. When the Royal Mail make an attempt to deliver a recorded delivery item the delivery does not happen. The item is taken back to the sorting office, and they will keep it for 1 week. A note is left with four options for how to get the item.

1. Go to the sorting office itself and collect it during the sorting office opening hours.
2. Get the letter redelivered to your home address.
3. Get the letter sent to another local address for free.
4. Get it sent to a local post office for you to collect.

This seems very reasonable at first glance but it completely fails to meet user needs. I would guess that most failed deliveries happen because the person and their cohabitants are all out at school or work during the day when the attempted delivery happens.

• If you have a normal fulltime job getting it redelivered to your house (option 2) is no good as there is no guarantee on delivery time.
• If you do not work in the local area, option 3 is no good, where are you supposed to get it delivered?
• The local post office opening hours are basically office hours, so option 4 does not help.
• The sorting office opening hours are weekdays 9am until 5.30pm, and Saturday 8 until 12. That information is from memory, because in another example of not being very user-friendly, I cannot find it using their website or google. So for the typical person who fails to have something delivered, they are left with a four hour window on Saturday or the delivery fails.

A user focused approach would think "Why has this not been delivered?" Then realise the answer was because the person was usually busy during the day. And then maybe offer some of the following options as well as or instead of the ones above:

1. An evening redelivery to a local address or your address.
2. One or two days a week, open the sorting office counter from 1pm-9pm. No extra staff time is required, in fact it might offer some staff a choice of working hours they would value.
3. Allow an option to pay to redeliver to a non-local address.
4. Allow a letter to be sent to the sorting office to authorise a non-signed delivery, with the signature on the letter counting as the signature.

So the three symptoms were met:

1. It was possible for me to get the item
2. It was not easy or convenient for me
3. It was made very easy and convenient for the post office

Interestingly, this isn't an example of not being customer focused. I was not directly the customer, udiggit were. I was a user. As such I have no monetary power to change things except indirectly, by not shopping with people who use special delivery, and insist on delivering to my home address. This is very similar to the software example, where the people choosing to buy the software, often the IT department, are different from the people who use it.

Code is for reading

Code is primarily written for programmers to read. Why don't people seem to realise that?

This is a rant I've wanted to have for a while, and have finally been pricked into it by a friend, Andrew Ketley making a comment about writing spreadsheets. He said:

The modern spreadsheet is no longer a simple tabulating and adding machine - it'a a highly sophisticated construction kit for certain classes of corporate applications, and needs to be approached as such....Hardcoded constants, obscure naming, spaghetti logic - it's all there.

Code is primarily written for programmers to read. Often that programmer is you - 5 seconds, 5 days, 5 weeks or 5 years later. Sometimes it is other programmers. If code was not written to be read, then we would all be happily writing in assembler, as the time to write assembler probably isn't that much slower that modern programming languages. What is slower is the time to test it, and modify it, whether those modifications are to add functionality, change functionality or remove bugs.

This is one reason why I don't like Perl, though many people love it. A motto of Perl is "There's more than one way to do it", and as a result people have a huge amount of freedom to develop different idioms in coding. And so reading the code is like understanding english spoken in lots of different accents. It might add to the richness of life, but it does not aid speed of understanding. A language with more constraints, like C, Java or C#, still allows personal style and idioms, but it tends to be much easier for one Java programmer just to pick up and read another's code.

However, in any programming language it is possible to write code that is hard to read, if you don't concentrate on readability. Readability is a very subtle thing, and something which is more readable for me might be less for you. It's analogous to spoken language again. If I am drunk, and mumble in a slurred voice everyone will find it harder to understand. However, with a southern English accent, another southerner might find me easier to understand than someone from Glasgow, whereas for someone from Glasgow it would be the other way around. Similarly, some code is just harder to read than other code. However, it is also true my colleague Jason might find my code easier to understand than Joel's, whereas one of the Aardvarks might find Joel's easier - neither is necessarily better, it is just more familiar.

So when you right code, you should try and make it more readable for everyone, and especially readable for the intended audience, for example, those on your project. This is one reason why coding standards are a good idea - which brace style to use does not matter, as long as everyone uses the same. This is one thing which heps cause the "Not Invented Here" syndrome.

So, I should get back to Andrew's point about spreadsheets. A spreadsheet is confusing because it presents two views to the world in one user interface. It presents a view to the user, who wants to use it to calculate something, and the programmer who wants to change how it does that calculation. And it can be good or bad at either. Normally the "user" user interface gets improved before the "developer" user interface, but I've written spreadsheets which were great to develop, but lousy to use. Normally the model-view-controller pattern will be helpful here for separating the two, but you could also use Smartspread, which provides a much better development environment, in my opinion, than Excel. But then I did write it, with Jason, so I'm biased.

There's lots more I want to rant about readable code, and I want to give some examples, but that can wait for another time.

Book Review: Better, Faster, Lighter Java

Better, Faster, Lighter Java
Bruce A. Tate & Justin Gehtland
ISBN 0596006764

A great book for someone else - about the worst thing you could say for a book.

The other week Vaughan Roberts, the rector of my church, was giving a sermon on the sermon on the mount. He was covering Matthew 7, where it talks about not judging:

Do not judge, or you too will be judged. For in the same way you judge others,
you will be judged, and with the measure you use, it will be measured to you.
Why do you look at the speck of sawdust in your brother's eye and pay no attention to the plank in your own eye? How can you say to your brother, 'Let me take the speck out of your eye,' when all the time there is a plank in your own eye? You hypocrite, first take the plank out of your own eye, and then you will see clearly to remove the speck from your brother's eye.

And he said that a very common reaction to this passage is to think "Well I know that, but I wish my friend Luke would read that"! (As far as I know, I don't have a friend called Luke.) Well on reading the Better, Faster, Lighter Java book, I had a very similar reaction.

It was full of good stuff, but things that I wish that my colleagues could read, rather than new ideas for me. Concepts like doing the simplest thing that could work, and not doing too much up front were prominent, which will be familiar to anyone who has tried XP. Now that makes it useful, because the authors explain concepts better than I probably would. Also it showed me that I am not alone in my opinion on certain programming topics. Also, if you didn't know about Hibernate (I did) or Spring (I didn't) it's worth reading, but now I've told you about them.

So I cannot give it a huge recommendation, as I cannot tell you much I learnt from it, it just made me feel self-righteous. I've lent it to one of my colleagues, and I await to hear what he thinks of it.

Three Level brands?

Something strange seems to be happening in the world of brand management.

We are all use to two level brands. That might not be the right term, but by that I mean names like "Microsoft Excel" or "Kellogg's Cornflakes". A company name followed by a product name. Apparently this has good legal reasons as a sensible thing to do (Joel's explanation - see "The Name"). But recently I've seen two three level brands emerge. They are things "Cadbury's Dairy Milk Caramel" and "Kellogg's All Bran Bran Flakes".

Until recently there used to be "Cadbury's Caramel" and "Cadbury's Dairy Milk" and "Cadbury's Fruit and Nut" but now they have all been renamed into "Cadbury's Dairy Milk X". Kellogg's have done a similar thing with All Bran, Bran Flakes, and Sultana Bran. I wonder why this was done. I could speculate, and probably will, but the best way of finding out has to be ask the companies involved, so I've done that using their online forms.

This article seems to suggest that it is because when launching new products, a brand extension is easier to get underway than an entirely new product.

Meanwhile, I'll keep my eye out for other examples.

Ideas Factory: Phone translator

Another idea for my personal effort at patent prevention - the phone translator.

I've been thinking of going to China on vacation. One thing that worries me is I don't speak the language at all. Hopefully a lot of things will be made easy by helpful Chinese people, good guidebooks and gestures, but some things remain scary. Two big problems are road signs and menus.

Now a bunch of technologies have become fairly solid and common in the last few years. These include OCR (optical character recognition), automatic translation, and mobile phones with Java and cameras. A great device would be something you could point at a sign or menu, and it would translate it for you into your language. A mobile phone seems like the ideal device to put this onto, as they often have a programmable computer, a camera, and a screen, and they are natural to take on holiday.

Obvious extensions would be to have something that would do audio translation, especially the other way, so I could type something in in english, and it would translate it and say it in chinese. That's probably too CPU and memory intensive for my mobile phone at the moment, but it should happen eventually.

There's nothing new under the sun! If you are willing to carry a laptop, something pretty good like this exists already: The PenPower Mini ScanEYE (note I haven't tried this but it looks cool). And even on the Wikipedia entry for mobile phones they suggest a translation function, but don't say whether they mean audio or text. They don't mention using the camera.

Route planning with Baby steps

I'm becoming more and more convinced that one of the most important skills for any programmer is route planning with baby steps, and I've never really seen anyone write about it.
I was first struck by this when seeing Kent Beck give an introduction to programming at XP2001, a conference about eXtreme Programming. He demonstrated writing some code to convert between an integer and the corresponding roman numerals using XP practices like writing test-first, pair programming, and constant refactoring. But the thing that impressed me most was the way the code seemed to emerge out of nothing, taking one small step at a time, with the code always working and always getting better.

Programming is very like walking. When you walk, to move forward you have to put yourself off balance, and run the risk of falling. But without that risk you will never get anywhere. In programming every time you change the code you break it. For example, in a standard editor, typing a single character means the code will no longer compile. This is like being off balance. When the code again compiles, runs and passes all the tests it is like being back on balance. A step forward is making a change that adds functionality or improves usability.

Any programmer can break the code. The most mediocre progammer if told what tiny step to take will usually be able to write code to take that step. Good programmers can envisage how to take big steps, writing a lot of code to solve a difficult problem. What was amazing about how Kent programmed was that he could see how to take a big step as a sequence of tiny steps, each of which left the code in perfect working order, with a tiny bit of added functionality.

Most programmers cannot do this, and it is a hard skill to learn. Good programmers often find it harder to learn, as when they take big steps they often get them right. The only way to get better at it is to force yourself to try it. When about to start making changes that will stop you checking in code for a week, see if you can make it a day. Or try and break a day's changes into an hour's changes.

I think, counterintuitively, that this leads to one of the biggest problems with XP. In XP, the customer has to present a sequence of small stories. The onus is put on them to break a product into baby step stories, and as I've said, this is not an easy skill to learn. The problem is not that the customer has a hard job, as XP acknowledges the customer is a key part of the team, and has a job as hard as the developers'. The problem is that this part of the customer's job is assumed to be easy.

By taking more baby steps, it is easier to deal with a changes in requirements, easier to test, easier to integrate with everyone else, and probably results in better, simpler code.

Ideas Factory: Market Research the Cluetrain way

In the spirit of giving my ideas, here's one I had about a new software product, like a search engine, but push instead of pull technology.

When I worked at a commercial research lab I used to get very frustrated with the lack of contact with customers. We had a building full of smart people, great at solving problems, but not knowing which problems was most important for the customers to solve. We tried to get more contact with customers, but it involved working through internal bureaucracy and politics, and researchers are never very good at that.

At some point I read The Cluetrain Manifesto, which during the dot-com era did seem a bit revolutionary, and it did manage to spawn a book, which was more than most dotcom ideas. Its focus on big companies being responsive to customers rang a bell with the problems I was having in the research lab. I started thinking about how we could be more responsive as a lab to solving the problems our customers really had.

If I'm a customer and have a problem with a camera, I'll probably search their website for technical support and google to see if anyone has complained on the web. And this searching usually finds something. Imagine if the moment anyone posted about a problem to a message board, newsgroup or mailing list a pre-stored search query was matched, and the message sent to the company's proactive customer service department. Or if it was a post saying "I wish I could get a camera that did X", this got found automatically and sent to the research lab who invented a way of doing it. Firms would be so much more responsive.

This would also be a fantastic tool for those in small companies. They could monitor the whole web for comments about their particular niche area, without employing an expensive market research department, or hoping that customers contacted them. In these days of the long tail being the latest business fad it would be incredibly useful.

Google have gone some way towards this with Google Alerts and I've just found out that GoogleAlert is a commercial service, but both of them only monitor the web (and news for Google Alerts). What about mailing lists, newsgroups, radio, TV, podcasts, blogs and a million and one future forms of media?

So in summary, the idea is registered users, with prestored search queries, matched against multiple forms of both push and pull media, with results fed to the user as a push service either in real time or in digest.

I had this idea in 1999 I think, when it was a good idea. I should have published it then, and then it might not be 2005 with us still not having the service available. The best people to do this are Google, I just hope they read this and take the challenge on.

An incentive to cheat

I've written a couple of articles already giving reasons why I'm not keen on Software patents. (Embrace and Extend, and 1% inspiration, 99% perspiration). I see no reason to stop writing them though, while there are so many other good reasons to oppose them. For example, consider all the economic reasons.

Now most economists think that by default regulation in the markets is a bad thing, if sometimes a necessary evil. Another no-no for economists are monopolies as they make things expensive for everyone. In fact, one of the few types of regulation that economists support is anti-monopoly regulation. A patent is regulation creating monopoly, so needs extremely good reasons for it even to be considered.

The normal reasons given for patents is that without protection people will not put the effort into research and development, only to have the ideas "stolen" by someone else. I disagree with this in most cases - being first to market with a new feature in software is often enough to start a success. And even without patents a company will require constant research and development to stay ahead of the competition, and so will do that R&D. I would argue that just as much innovation happens in the open source world as in the commercial world in software. Innovation happens because people have a problem they want to solve. Of course there are counter-arguments to this. However, let us look at some other economic arguments against patents, especially software patents..

In "The Armchair Economist" (a good book) Stephen Landsburg argues that economics can be summed up as "people respond to incentives". I'd like to look at some places where the incentives lead to the wrong result.

The first place is in the pay structure. Patent Office examiners are government employees, and get paid worse than in the private sector (though they do have some nice perks). So if people were only motivated by salary, you would get worse people checking the patents than the law firms who help file most of them. In my experience however, checking for prior art for a patent is actually harder than having the idea in the first place, as you need someone who is intelligent enough to understand the idea to spend a lot of time doing a lot of tedious searches. It must be even harder in the patent office where you only have the horrible legalese that patents are translated into, rather than having a human being to answer your questions. And it would seem very difficult to incentivise patent office inspectors to do a good job when more and more patents are filed every year giving a bigger and bigger workload.

Secondly, consider the following situation. Once when I was in the process of preparing to file a patent, I spent weeks diligently looking for previous publications which might have shown someone else had thought of the idea first. Eventually, a couple of days before we were due to submit the application, I found a paper in an obscure japanese journal which theoretically covered my idea. Let's look at my incentives. By that point I was an expert in the area. I knew that if I submitted the application there was no way the patent examiner would have found this paper, the link between the paper and my idea required expert knowledge to understand. So the patent would have been granted. Also, investors think that patents are intellectual property, so more patents protecting key ideas mean that you have more property. So your must be company more valuable. So if I filed the patent I would have increased the value of my company through research, and made my boss happy, and increased my chances of a higher salary and promotion.

Finally, getting a patent invalidated even if it has prior art is an expensive, slow process, so if someone did use the idea it might be cheaper for them just to pay a license fee or swap patents than to actually get the claim revoked. So all the monetary incentives meant I should have filed.

For many small startup companies struggling to get investment the temptation must be there to file patents, as they will almost certainly be granted, and then they look good to investors whether they are valid or not. This has to be a bad thing.

I'd love to do a research project on this. Pick 10 software patents filed in the last 5 years in the US. Get some trained researchers to really search for a few months for each of them looking for prior art, with the best tools available. If prior art is found, go through the whole process of getting as many claims as possible invalidated. From this you could get an estimate of how many bad patents are filed, and how much it costs to invalidate them.

For more on this issue see Tim O'Reilly's page. Unfortunately the BountyQuest project that it mentioned died a death.

I never did file that patent.

Book Review: Trend Following

Trend Following - How Great Traders Make Millions in Up or Down Markets
Michael Covel
ISBN 0131446037

This book is a useful introduction to the philosophy behind trend following and some evidence for its success, but is written like a fiery sermon from a true believer, rather than a fair evaluation.

In 1989 Jack Schwager wrote Market Wizards. He interviewed many of the traders with the most impressive or consistently good trading results, and asked them sensible questions about themselves, their methods, and their beliefs on what it took to be a good trader. He had a background as a trader himself, but tried to listen openly, and not be judgemental and report accurately, focusing on similarities and differences in the answers he got. It led to an excellent book.

Michael Covel's book clearly wants to be a new "Market Wizards", focusing on Trend Followers. Trend Followers are traders who trade not from any understanding of the underlying fundamentals of the market or prediction of the future, but on the belief that human nature means that markets going up will tend to keep going up, and markets going down will tend to keep going down.

Unfortunately, the book reads like it was written by an enthusiastic person who has been hanging around some very smart people and hero worships them. Covel seems to think Trend Followers can do no wrong, and non Trend-Following traders are stupid and destined for a fall. For example, he consistently says that trend followers don't make predictions about the future, and derides non-trend followers for making such predictions. However, every time a trend follower goes long they are predicting the price will go up, and if they go short they are predicting the price will go down. Of course, they accept that their predictions will often be wrong, and get out quickly, but the implicit prediction is there.

Also, despite his claim "if we could have developed a book comprised of only numbers, charts and graphs of Trend Following performance data, we would have", there is very little hard data. What data there is, is usually presented very badly, for example, 3D absolute return bar charts with a log scale. I think he really needs to read Tufte.

If you want to read some useful quotes about trend following, and get a good feel for their philosophy then I would read this book, but don't read it as a balanced debate on different styles of trading.