What good software does for it's users

or Choice Sucks

I was reading Paul Graham's latest weblog [1] on how to make a lot of money writing software. Like any greedy person, I'm trying to come up with some software that's going to make me rich. Like Paul, I had been slowly coming to the realisation that developers didn't like purchasing software. So, I decided to take Paul's advice and try to think of what non-developers would want out of their computers.

This is harder than it looks. I don't really know many non-developers. All of my friends are software people. They tend to be married to other people in the IT industry. It is very hard to figure out what people want when you don't really have any experience. :) As I sat in bed mulling over the problem, my brain started to make associations. I realised that there was a connection between useful software, "The Long Tail" [2], and psychology.

I remember reading that people consider choice to be hard and stressful [3]. Everyone is very afraid of making the wrong choice. This is why we spend so long trying to figure out what breakfast cereal we want to buy. Check it out - next time you are in the grocery store, see how long you spend deciding. Now, think of how long we spend making more important decisions. How stressed we get worrying if we made the correct one or not.

The Long Tail [2] says that web businesses like Amazon and NetFlix do really well from being able to stock more titles than their bricks and mortar competitors. That they receive a substantial number of sales from the titles that they can stock but their non-on-line competitors cannot.

My epiphany was this. That the stress we feel over making a decision leads to the popularity of the long tail. Follow me in this. In order to better drive customers to other items, Amazon implements a review system. They then start to track purchases and make recommendations to their customers. This pushes people down into the tail. Why though? It works because people are afraid of doing the search themselves and making the wrong choice. They only really know that they want to purchase a book. They don't really know what they are looking for. So, Amazon's recommendations are as good a place to start as any, better than browsing the store themselves.

So, people willingly let the computer do the filtering for them. Does it always work? Nope. Is it a less stressful purchase? Definitely. The customer knows that someone out there, not completely unlike themselves, has also enjoyed this book. This means that it is probably not that bad.

This led me to my key realisation. Good software removes choice from the user. That doesn't mean that it doesn't make it possible for the user to see all the nitty gritty detail, just that it hides it as much as possible. Apple realised this, look at the interface on the iPod Shuffle. Mac software is all about hiding complexity.

So, truly useful software should help the user make decisions. It should remove grunt work from the user. For example, in the UK there is a web page that allows people to compare electricity providers. You enter your monthly usage and address, and out pops the cheapest provider for you. That helps the user make a decision. It means that the user no longer has to stress about which supplier to use, they just ask the system.

Good software should make (if possible) as many decisions for the user as possible. If the user ever answers a question, the software should never ask it again, and use it to answer other questions for itself. Software should be more about the assumptions it makes for the user. In most cases, the user won't care about the assumptions that are included, they will be the correct ones. Amazon's one click shopping is a good example of this. The user only has to setup the system once, after that all that they have to do is indicate that they are buying that item there.

This is a fine line. I'm not talking about autonomous agents that go off and do it all for you. Helpful software like Clippy is just plain annoying. Predictive text messaging isn't. It may sound like I'm saying that people are sheep. I'm not! I'm saying that the goal of a computer system should be to remove complexity from the problem. We shouldn't be adding decisions to a problem, we should be removing them.

References:

1. The Long Tail
http://www.wired.com/wired/archive/12.10/tail.html (original article) http://longtail.typepad.com/the_long_tail/ (web log)
2. The Paradox Of Choice: Why More Is Less
http://www.amazon.com/exec/obidos/tg/detail/-/0060005696/qid=1111411407/sr=8-1/ref=pd_csp_1/002-2296419-5280060?v=glance&s=books&n=507846 http://www.newyorker.com/critics/books/?040301crbo_books http://science.slashdot.org/article.pl?sid=04/03/29/1214225&tid=99&tid=14 http://www.healthpromoting.com/Articles/articles/major.htm http://www.lowellgeneral.org/features/health/foryourhealth/AIHspring99/AIHstress.htm
3. Paul Graham essay on startups
http://www.paulgraham.com/start.html

The Importance of Dates

Or: A project without an end date never finishes

The project I am working on is moving into the grey area where it will never finish. There are new releases every week, and while each release is better than the last, it isn't perfect.

The problems are caused by two things. The first is the lack of a project plan. Without a project plan, no one knows when the project is late. This was done intentionally by the customer's project management team to avoid internal political problems with not meeting a date.

However, this has a couple of flow on effects. Without a schedule, the development team (who is 12 timezones away) doesn't feel any pressure. They don't know if the software is good enough for delivery or not. They don't know if they should be pushing back on additional features in order to bring the project to completion.

Without a hard, or semi hard, end date, there is no common focus. There's no way to cause the customer's team to start making hard choices. They don't seem to be thinking "If I get one more feature, I'm delaying the project by 3 weeks". Without a date, they have nothing to fix their sight to, and there is no reason for them to not ask for more features. There's no weighing of the value of a feature, only a push to get everything included.

Finally, without a date, customers become frustrated. The parts of the customer's organisation not asking for new features begins to wonder why the project isn't finished. They look at the software and see it just as buggy between releases because the focus is still on additional, customer requested features. The people who are then waiting become frustrated, and express that frustration up their management chain. This then results in a disconnect between the customers view of the software and the development teams view. The developers look at the project and think they're doing well, they're responding to customer requests quickly. The customer looks at the software and sees something that isn't finished and they don't know why.

I believe that while there may be political reasons to not have a fixed, communicated end date, the various parts of the team do need to have one. Without that, there is no way to tell if things are achievable or not.

This could also be a failure of communication between the customer and the developer, or even internally at the customer. A harder line on change control would help with the creep, but it tends to result in frustration for the customer because they want their important changes implemented quickly. The trick is to get the customer to do the filtering, and accept the impacts of their decisions.

One final thing. Always make sure that your external milestones are not the same as your internal dates. Otherwise, if there's any slippage in your internal date, it becomes immediately visible externally. It is always best to have a little bit of room between those two dates to buffer the customer from the slips and recoveries in the dates.