Rowan Simpson

Peter Norvig (the Director of Research at Google) started off his ETech presentation with a diagram showing how things used to be (back in the old, old days … like 1994):

At the core, in the past, was the algorithm. Inputs were pretty simple (mouse clicks, keyboard entry). Outputs were equally simple (text, user interface). Data was used simply as a store of input and output. All of the effort and focus went into creating smart algorithms.

However the massive data sets that Google now has access to allows them to flip this model around. Rather than creating complex, elaborate, (and probably inaccurate) algorithms by hand they instead use a simple statistical model and let the data do the work.

He gave several examples. The most obvious is the Google spell checker which using this approach can guess what you might have meant, even where the words you’re looking for don’t appear in any dictionary (e.g. http://www.google.com/search?q=rowan+simson).

Another is their translation tool which can be trained to convert any text where there are enough examples to “learn” from. Ironically, the limiting factor now with this approach is not the software but the quality of the human translators used for training.

In each case being able to do this simply comes down to having enough data.

This is one of those ideas which is so obvious after you’ve seen it:

If you have lots of data the way you think about algorithms changes completely

Phil from Xero pointed me at this article about XMPP (a.k.a. Jabba):

XMPP (a.k.a. Jabba) is the future for cloud services

What do you think? Has anybody done anything interesting with this that you’re using or know of?

It would be interesting to hear about how you find it.

Here’s an interesting response to the great Marc Andreessen post on Product/Market Fit (which I can’t believe I haven’t linked to from here before now!)

“What’s the right attitude? Humility. It doesn’t matter how smart and successful and qualified you are, you simply don’t know what you’re doing. The good news is that nobody else does either, though some are foolish enough to think that they do (and that’s why you can beat them).

What is the humble approach to product design? Pay attention. Notice which things are working and which aren’t. Experiment and iterate. Question your assumptions. Remember that you are wrong about a lot of things. Watch for the signals. Lose your technical and design snobbery. Whatever works, works.”
– The most important thing to understand about new products

I like the idea of humble product design.

Paul used to work for Google and was the guy who wrote Gmail.

His own story is a goodie:

“I wrote the first version of Gmail in one day. It was not very impressive. All I did was stuff my own email into the Google Groups (Usenet) indexing engine. I sent it out to a few people for feedback, and they said that it was somewhat useful, but it would be better if it searched over their email instead of mine. That was version two. After I released that people started wanting the ability to respond to email as well. That was version three. That process went on for a couple of years inside of Google before we released to the world.”

I’ve had a couple of opportunities to meet Mike Cannon-Brookes from Atlassian in the last 12 months, first at Morgo and more recently at Kiwi Foo Camp.

He is a nice mix of very smart but still approachable. I like that.

Atlassian are an impressive company, and a good role model for a couple of the businesses I’m working with.

He recently blogged about an experiment they are running at the moment where they are allowing staff to spend 20% of their time on their own pet projects. This in itself is obviously not an original idea. What makes this interesting is that, unlike Google, they are going to be open about how it works for them in reality:

Atlassian’s 20% Time Experiment

Lots of companies talk about doing this sort of thing, but hardly any I’m aware of have actually gone as far as trying it out. Doing so in the open is pretty brave. Here is what they say about the potential impact on customers:

“What does it mean for customers?

In the short term, this will mean slower or smaller, but more innovative releases. How much slower, smaller and more innovative? We’re not sure - we’ll find out and be honest in communicating it here.

(From my back of the envelope calculations, for 7 products we’ve made over 50 releases in the last 12 months.)

The long term thinking is that some of the 20% results will filter into the products and outweigh the short term release slow down in terms of customer benefits.”

You have to give them credit for that at least.

I wish them luck, and will watch with interest to see how it goes.

This is Part II in a two-part series. Part I was published on 24-Jan.

Another one from Guy and Garr …

Question: What is the single most important thing people could do to enhance their presentations?

Answer: Turn off the computer, grab some paper and a pencil, and find someplace quiet. Think of the audience. What is it they need? What is it you want to say that they need to hear. Identify what’s important and what is not. You can’t say everything in a twenty-minute talk—or even a two-hour talk.

The problem with most presentations is that people try to include too much. You can go deep or you can go wide, but you can’t really do both. What is the core message? This time “off the grid” with paper and pencil or a white board is where you can clarify your ideas and then get them on paper visually. After your ideas and basic structure are clear, then you can open up the software and start laying out the story in the slide sorter view.

Replace the word “presentations” above with “software” and the same great advice holds, I think.

Certainly the part about turning off your computer and spending some time thinking about what your audience needs and considers important, as tempting as it is to jump straight in and start coding.

But the real gem here in my opinion is the observation that you can go deep or wide but not both.

Just like presentations I think that most people building software try to include too much. Adding more features is a natural inclination. It’s actually ingrained in the social order of software developers - within teams enhancing existing features never seems to have the same status as adding something new. But, it should.

Can you have both the most features and be the easiest to use?

When you look around there are not many examples of software products which have achieved this.

So which of these two alternatives are you choosing, consciously or otherwise?

This is Part I in a two-part series. Part II was published on 25-Jan.

Garr Reynolds from Presentation Zen (who I’ve linked to before) recently answered a bunch of questions for Guy Kawasaki.

Ten Questions with Garr Reynolds

It’s a great post and I recommend that you read it. But a couple of the questions and answers especially jumped out at me. I thought it was worth highlighting them here - one today and one tomorrow.

Question: Are PowerPoint and Keynote part of the problem or part of the solution?

Answer: There is no question that PowerPoint has been at least a part of the problem because it has affected a generation. It should have come with a warning label and a good set of design instructions back in the ’90s. But it is also a copout to blame PowerPoint—it’s just software, not a method.

True, the templates and wizards of the past probably took most of us—who didn’t know any better anyway—down a road to ‘really bad PowerPoint’ as Seth Godin calls it. But today we know better, and we can make effective presentations with even older versions of PowerPoint—often by ignoring most of the features. Ultimately it comes down to us and our skills and our content. Each case is different, and some of the best presentations include not a single slide. In the end it is about knowing your material deeply and designing visuals that augment and amplify your spoken message.

How depressing to have an expert like Garr is telling people that the best way to use software is to consciously avoid features. Of course, he’s right. But, what a waste of time spent designing, developing and testing those features. Imagine instead if that time was invested in those parts of the software that people should use.

What’s more, not everybody is lucky enough to read this sort of advice. Death by bullet points is still the most common presentation experience.

Who is responsible for that outcome?

Those of us who design software should always focus on guiding users directly into “The Pit of Success”.

“In stark contrast to a summit, a peak, or a journey across a desert to find victory through many trials and surprises, we want our customers to simply fall into winning practices by using our [software]. To the extent that we make it easy to get into trouble we fail.”

– Rico Mariani, Microsoft Research (quoted by Brad Adams).

You need to make the right way the default. A new user should be able to just follow their nose, make the obvious choices, and end up in the right place.

Of course, this requires that you take a view about what the “right way” and the “right place” actually are (even where this requires you to be a bit of a dictator).

I think this is where software developers often let themselves down - by giving users almost unlimited flexibility, giving all features equal prominence in the navigation, by adding all of the features that users ask for (as opposed to those features that are required to get them most directly to the desired place), etc etc.

Those working on PowerPoint over the years have fallen into all of these traps.

As have many of us.

BONUS: Garr has a new book, also called Presentation Zen. If you do any public speaking, or even in-house presentations at work, go get a copy.

Is it bad form to quote Fake Steve Jobs now that he has been outed?

Either way, here is an interesting quote from his blog:

“Yes, there are smart people at Google. Smarts are about one tenth of what makes a business work. The rest is just shitty stuff like dealing with customers and partners and fixing bugs and reworking code and doing all sorts of lousy grunt work — stuff the little whiz kids don’t want to get their hands dirty on.”

From: Squirrel boy gets his turn in the clown chair

Here is a nice (old) post from Sam Ng at Optimal Usability about Ben Goodger’s presentation at Webstock last year:

“Ben Goodger, lead engineer for the Firefox browser, obviously believes in the power of the user interface and credits their ‘less is more’ philosophy as one of the key reasons for the browser’s success. As part of this philosophy, they made sure that the interface was clear, removing words or interface elements wherever they could to increase clarity. They also had fewer and more useful options, only including a configuration option if 15% or more of users were likely to change it. And they worked hard on using smart defaults, like turning the pop-up blocker on. All these small changes created a ‘cumulative feeling of quality’.”

From: http://www.optimalusability.com/post.php?postid=31

Designing for the 80% majority (or 85% in this case) is a great idea.

Sam - this is good stuff, what’s happened to your blog?

Phil Haack has a great post listing 19 different laws of software development. Everything from Postels Law, to The Pareto Principle (a.k.a. the 80/20 rule), to Wirth’s Law (software gets slower faster than hardware gets faster), to Sturgeon’s Revelation, even Murphy’s Law gets a mention.

My favourite?

One I hadn’t heard of before, but which definitely marries with my experience:

“Conway’s Law: Any piece of software reflects the organisational structure that produced it.”

What’s the shape of your org chart? And how is that manifesting itself in your code?

UPDATE: Wikipedia has a much longer list, if you’re into this sort of thing. :-)

There is no shortage of great job opportunities in Wellington at the moment.

The three guys who founded Mindscape are looking to expand their team.

Same for Trade Me (Senior Web Developer & Project Manager) and Xero (Developers, Tech Ops Manager, Business Systems Analyst, Test Analyst, etc) and I’m sure others

If you’re current job is a death march, or just doesn’t do it for you, you have no excuse.

Phil Haack has an interesting post about the difference between the most productive developers and us mere mortals.

His conclusion:

“By writing less code that does more, and by writing maintainable code that has fewer bugs, a good developer takes pressure off of the QA staff, coworkers, and management, increasing productivity for everyone around. This is why numbers such as 28 times productivity are possible and might even seem low when you look at the big picture.”

From: 10 developers for the price of one

He’s absolutely right (imo).

Some developers are much more productive than others.

And, it’s very difficult as a manager to find the right way to recognise this without stepping on toes.

At least that’s true in the short term.

In the long run the cream normally rises to the top.

Some interesting responses to my post yesterday about the evergreen VB.NET/C# debate.

Andrew from Mindscape makes the point that every different language has “different levels of expressiveness and also different aesthetics.”

Quite right.

He posts this Ruby code snippet …

10.times {|i| puts i }


… and asks “Which do you find more beautiful?”.

The VB.NET equivalent is:

For i As Integer = 0 To 9
Console.Write(i)
Next


I agree that the Ruby code is beautiful.

However, I’m not sure that is the right thing for us to optimise on.

How about optimising for readability? Most code is read much more often than it is written. When we’re designing databases we understand what this means. Adding an index to a table adds a small cost to every write, but it’s worth it in situations where there are many more reads than writes. But we don’t seem to apply the same principles to the code we write.

I’ve worked on a few different applications now and can’t think of any where the limiting factor was the number of keystrokes in the code. And as a couple of people have pointed out a good IDE setup can significantly help with this anyway.

MVP Alex calls the VB syntax “ridiculously clumsy”, and points the finger specifically at keywords like Overridable, NotOverridable, and MustOverride.

I guess that depends on what language is native for you. For me, when I read ‘virtual’ (a term that can actually mean 1000 different things depending on the context) I have to translate that into ‘able to be overridden’ or ‘overridable’. I’m not the only one.

You say tomato, I say tomato.

And that was really the point I was trying to make.

An argument between two developers about which language is “best” is like a debate between an Englishman and a Frenchman. Each will prefer their own language. And each will be right because they will both be able to express themselves best in their own native language.

And again, while the debate continues, important problems remain unsolved.

:-)

Kirk (one of my new colleagues at Xero) and Phil (one of my old colleagues at Trade Me - Phil, where’s your blog?) have organised a C# vs. VB.NET debate for the Wellington .NET users group tonight.

Should be fun.

My predictions:

• Most of the audience will be C# developers;
• Few of them will have ever used VB.NET in anger;
• Despite that, they will have already convinced themselves somehow that VB.NET is inferior;
• None, if challenged, would be able to build anything using C# that Phil couldn’t build just as well in VB.

Meanwhile, important problems remain unsolved.

:-)

Update: I’ve responded to some of the comments and emails generated by this post in a subsequent post called Parlez vous Anglais?

Are you taking advantage of the web platform and constantly making small improvements to your software?

Or have you got an excuse for why this is too hard (your application is too complex, you can’t easily deploy changes without interrupting users, you can’t afford the testing costs associated with each release, you prefer to focus on the bigger headline stuff, etc, etc)?

Here’s what Google achieves …

“… half a dozen major or minor changes are introduced in Google’s search engine every week, and each change can affect the ranking of many sites — although most are barely noticed by the average user.”

That’s the benchmark.

This is my new favourite Hugh McLeod cartoon:

It currently has pride of place above my desk at Xero.

On the other hand …

This from Jimmy Gutterman:

“There are only two industries that refer to their customers as users: high tech and illegal drugs.”

Surely we can come up with a better name than “user”?

Like Luke Welling, I suspect that reports of the death of Computer Science has been greatly exaggerated.

“The death of computer science was a fairy tale in 1987, and 20 years later it is still a fairy tale. More powerful computers are not replacing programmers any more than calculators are replacing accountants or power tools are replacing carpenters.”

Read the full post.

Here is a simple rule: if you’re building a web site make sure it:

(1) works; and

(2) looks good.

The order here is important.

What does it profit someone to have a site which looks like a million dollars but which doesn’t actually work?

Here is my theory: the better a given web site looks the less likely it is to actually work.

A recent example …

Both Rod and Nic have raved about their Blackbox M-14 headphones, made by NZ company Phitek.

I figured I’d get me some of that noise canceling goodness.

(and, in case you’re reading this Larissa, this purchase decision was not influenced by sitting beside you this week! ;-)

I had an uneasy feeling from the moment I hit their home page. The main navigation links unfurl onto the page in a very pretty (but otherwise pointless) Flash animation.

The real fun started when I got to the check-out.

There are pretty well understood conventions now for how an online check-out should work. Don’t make me think.

Instead, here is the Blackbox check-out page:

So, I select the product I want and click the “Go To Payments Page” button.

An error message is displayed: “Please check your personal details”.

Eh?

It turns out that all three steps are contained on one page - with the second and third steps hidden in collapsed sections at the bottom of the form. To get to the second step I need to click on the “Review Purchase Summary” bar, although there is nothing to indicate that it’s a link. It doesn’t look clickable, and the mouse cursor doesn’t even change to a hand when I hover over it.

Then, having made it through the form I get this:

Unfortunately, the re-direct doesn’t work. And there is no obvious way to click-thru manually. I can’t get to the page where I enter my credit card details.

The net result: I haven’t purchased the headphones and my confidence in their brand is dented.

I wonder how many sales they miss because of a website which looks great but which doesn’t work?

Here is an idea that has been bubbling in the back of my mind for a while.

I don’t have the time at the moment to make it a reality, but if there is a smart developer or two out there looking for a project give me a shout.

The problem

It is very difficult to ensure that all of the page in a large and dynamic web sites contain valid HTML, especially as changes are made to those pages over time.

Why?

There are a few reasons:

• It is very time consuming to manually validate a large number of HTML pages. And it’s hard to make the case for spending extra testing time on this.
• Dynamic pages change (duh!) so it is difficult to validate all of the different permutations.
• Pages that require users to post information in a form or login cannot be easily accessed by an automated test script, so are often not validated at all.

The solution

While developing and testing a site, or even just while browsing, we typically visit a large number of different pages.

The proposed tool will run in the background while we use the website and capture the details of each HTTP request and corresponding response. The HTML that is returned can then be validated asynchronously by the tool.

At the end of the browsing session (or even during, if required) the tool will provide a list of the pages that have been visited and a count of the number of warnings or errors contained on each. The user will be able to drill into the details of any page to investigate the cause of the warnings or errors.

This would allow developers and testers to quickly and easily validate a large number of pages, including those that require users to post form information and login, without any extra work over and above what they are already doing.

Required Components

1. A program that runs in the background collecting details of each HTTP request and HTML response

Perhaps this would be a Firefox extension? Or, a Windows application that hosts IE in a sub-window?

The user interface should be very simple (e.g. start/stop button, plus perhaps an indicator of the page count and/or total warnings/errors or a summary of the previous request a la the Firefox HTML Validator add-on (btw, does anybody know of an equivalent add-on which works on a Mac?)

2. An XHTML Validator

This would ideally give equivalent results to the W3C validation tool, which will require an SGML parser (but if this is too painful it could just implement HTML Tidy-like validation for starters)

This could also be extended in the future to validate CSS, JavaScript, and also run standard accessibility tests.

3. Result viewer

A simple web interface, with two views would do the trick:

• List view
  • Identify each page by URL and/or HTML title
  • Identify pages which contain errors (perhaps using simple green, orange and red light icons)

• Details view
  • Lists all warnings/errors for the selected page (with HTML snippits)
  • View full HTTP request and response details

Extra for experts

It would be nice to allow the user to compare results for a given page to the results from previous sessions, so that trends can be identified.

Comments welcome

What do you think?

Would something like this be useful?

Does something like this already exist?

If you have any thoughts or suggestions comment away. :-)

There has been a lot of interesting discussion around my posts last week about the new Vista sidebar gadget and XML feed and follow-up about why Trade Me doesn’t have an API.

Thanks to everybody who has contributed. Be assured that your comments have been widely read here at Trade Me.

If you didn’t already feel free to add your 10c worth.

A couple of things that are worth following up …

Firstly, people have been busy building wadgets of various persuasions and I promised to provide some links:

• Nigel has created an iGoogle widget
• Damien has created a JavaScript plug-in called GadgetMe which you can use to easily add your Trade Me listings to your blog
• Charles has converted the feed into a mobile friendly format
• Mike has used Yahoo Pipes to create an RSS feed - and is asking for people to help to extend this
• And, let’s not forget the one that started it all: the Vista sidebar gadget built by Darryl and Jeremy

I’d be interested to hear from anybody who is using any of these? Are you finding them useful?

There are a few others I’m aware of which are still “under development”, including an OS X widget which Ben and the guys at DNA are throwing together. I’ll post more links here as they come to my attention.

If you’d like to build something but need some inspiration, check out the recently released eBay companion for Firefox. A browser add-on which lets people track their listings in the sidebar of the browser like this would be wicked.

Secondly, a few of the comments I received warrant a response:

“I think it’s a bit rich to say that you don’t want other people to build things you might eventually build yourselves. I’d be more inclined to accept that argument if you were likely to get to new features. And, don’t forget, while you sit worrying about what you *might* do at *some* point in the future, your users don’t have the features.”
– Nat Torkington

Fair point. We’ve been threatening to build our own listing tool for a few years now without much to show for it. In the meantime people behind tools like Auctionitis have got on with actually building something, which has proved to be a much more effective strategy!

“A cynic might say that the real reason you don’t have an API is because you already own the sector.”

– Nat Torkington (again)

Ouch. Nobody is that cynical are they Nat?

It’s true that “want to” and “need to” are two different things. But, I think this comes back to my point about having bigger fish to fry. Whenever we decided to invest time in some new functionality we are, at the same time, deciding to not invest time in something else. For each thing we do there is a long (infinite?) list of things we don’t do.

Of course there is also an argument to say that an API would help to alleviate this by letting others fry the smaller fish we don’t have time for. It’s unlikely, for example, that we would have ever prioritised the various tools that have already been built on top of the XML feed (see above) but some people are obviously finding those useful, which is all good.

“I think that lots of NZ websites are afraid to offer feeds as they believe that this will stop people from visiting the main site. Those that do offer feeds, don’t provide full-text feeds, for that same reason. The idea is that if you offer a partial text feed it will encourage users to click through and visit the main site, but this has been proven to be untrue.”

– Stuart

I agree it would be great if we could provide more RSS feeds. The “My Favourites” page would be the obvious place to start and new listings within the “$1 reserve” page would be a close second.

The reason why this hasn’t been done has nothing to do with wanting to drive additional traffic to our site. We have lots of traffic already. If anything, would probably appreciate taking some heat off our listing servers. RSS feeds, which are smaller than HTML pages and more easily cached would only help with this.

“Any of us could (and some have) easily talk through the issues raised in Rowan’s blog and come up with solutions to the objections regarding versions, support, development time etc etc.

But I believe it falls into the above category because the underlying issue is simply one of trust.

Do they trust us, the people out here, to build things that will increase their value instead of subverting it.

If you’re basically inclined to trust people, then you’re going to be able to invent a million reasons why giving them a means to add value to your business by building their own is going to work.

If you’re basically inclined to distrust people (at least in this context), you will be able to discover a million reasons why it could all go horribly wrong.”

– Richard Clark, in the NZ 2.0 Google Group

I agree with the first part. I’m sure we could find solutions to all of the road blocks I listed.

But, I think it’s a bit unfair to say that reason we haven’t done this yet is because we don’t trust people. Our whole business is built on the premise that most people are trustworthy. Everyday thousands of Trade Me members send money to people they have never met for goods they have never seen. That requires a lot of trust!

“Do you know of any other NZ web companies apart from ZoomIn that are aiming at consumers and have released APIs?”
– Peter Griffin, via email

A good question? I can’t think of any. How about you?

This is something we’ve been talking about internally for a while, so it’s really interesting to get a broader perspective.

Thanks again for being part of the conversation

I notice that John is looking for some smart students to be part of the next Summer of Code.

(I have to admit, looking out the window this morning it’s hard to imagine a summer of anything, but let’s not dwell on that!)

I really enjoyed presenting and generally just being part of this the last time around.

Looking at the list of companies involved this time around, there are going to be some awesome opportunities for those selected.

If you’re a smart Comp. Sci. student you should be all over this!