Agile Teams, Open Software, Passionate Users

It Takes a Community to Raise Great Software July 2, 2007

Last week, I outlined the criteria I felt were most important in Version Control software and focused on Adaptability. This week, I want to focus on #3 on that list – Usability. What aspects of usability really matter? How can we maximize the chances of building great software that users will love to use? These are important questions relevant to most software teams in my opinion.

Many teams makes the mistake of thinking that usability is primarily about ease of use. Other teams make fast performance their main focus and make compromises accordingly that hurt overall usability. Both ease of use and fast performance are important but the real key to usability is task efficiency.

In the end, users simply want to get things done. Ease of use is important because it lowers the time required to learn software. Easy to use software also assists users complete infrequent tasks (which can be most tasks for casual users). Performance is important because time is a precious commodity in our busy lives and every few minutes – even seconds – count, particularly for power users. However, focusing on these and forgetting task efficiency is a massive mistake, one so large that it almost cost the IT industry its credibility in the business world …

That might sound a bit melodramatic but it’s not too far from the truth. Personal computers took off in mid 80s because WordPerfect, Lotus 1-2-3 and dBase III let users do things far more efficiently than previous technology allowed. 10 years later though, the IT industry was looking like a crowd of charlatans and I was frankly ashamed to be part of it. Why? Because the IT marketing crowd had conned the world into spending mega billions of dollars on faster performance and ease of use. Yes, the computers were vastly better and Windows, Word, Excel and Access were easier to use than the applications they replaced, but the Return On Investment simply wasn’t there – it still took users just as long to churn out the same documents as before, albeit with more fonts than before. 🙂 It took the arrival of the Internet and the Wide Wide Web in particular to put the focus back where it needs to be: technology empowering people to get things done more efficiently. (If there was justice in the world, Tim Berners-Lee would be the richest man on the planet instead of Bill Gates.)

So what does all that have to do with version control tools? Quite a lot as it turns out. It means that investigating and selecting any one of the new breed of tools – Arch, Bazaar, darcs, Git, Mercurial, Monotone and SVK – is smart thinking because these tools can empower your team to work more efficiently. It also helps explain why I think choosing Bazaar in particular is a wise choice: its primary usability focus is task efficiency. I’m very pleased to be working hard right now on improving Bazaar performance because I want it to be faster than it is. I’m even happier though when I hear core team members stress that performance will not be improved at the expense of doing the right thing.

Make no mistake about it, good usability is hard. The most important rule is ensuring you have a rich domain model at the core – beauty is never skin deep. In this respect, I think Bazaar has got it right. For example, by correctly tracking renames and merges, I know Bazaar will help me get my work done faster. It simply doesn’t matter if it takes a few seconds longer to do a merge (say) than the competition, because every and now and then other tools might well cost me hours or days cleaning up problems caused by lack of proper semantic modeling. In the same spirit, every single message to the user matters because an unclear explanation about something can cost new users hours in lost time. In this regard, I feel Bazaar is below where I want it to be. Enter the Bazaar community: many of the patches submitted for Bazaar are improving this aspect of the product in every release. And that’s a common pattern with many software products because the core team are often too close to see ease of use issues clearly.

Returning to a broader context, there is a law of software every team should have on their wall …

For any piece of software, the secret to greatness is a great community.

This is well understood in the open source world but it applies equally to commercial software where a critical mass of users takes time. There is a wisdom in crowds that small teams simply cannot match. A good community ensures that ease of use, performance and task efficiency all get attention, with task efficiency ultimately getting the focus it deserves. In a very real sense, raising software is a lot like raising kids. It takes a community to raise great kids, even if they have the best parents on the planet. Project leaders, like parents, need to be loving, set direction and ground rules but it takes much more than that: it takes an extended family, neighbours, schools, etc., all providing different viewpoints and growth opportunities.

When I look to the future, I like what I see in the Version Control software world. Bazaar has great parents who got it right with respect to task efficiency and a rich domain model. But even more importantly, it has a great community behind it that is rapidly helping it mature in all the right ways. Other popular DVCS tools like Git and Mercurial are equally blessed, and all of these communities are learning from each other. If you’re looking for empowering technology to get software built faster, give DVCS a go. You’ll never go back to CVS or Subversion again and, with an adaptive approach, you’ll never need to to!

Advertisements

Like this:

LikeLoading...

Related

I agree with the importance of user efficiency, although I have often seen it incorrectly measured and encouraged. For example, some software projects try to improve user efficiency by reducing the number of mouse clicks required to complete a task, or even trying to reduce the average time taken to complete a task. The problem I have with this is expressed in the title of Steve Krug’s excellent book: “Don’t Make Me Think”. As an software user myself, I would rather five ‘easy’ clicks not requiring thought than two or three ‘painful’ clicks requiring a large amount of thought for each click.

I personally do not like the term ‘task efficiency’ as I think it may discourage consideration of ‘goal efficiency’. By considering ‘goal efficiency’ we acknowledge that there are different ways a user can use software to achieve their goals.
For example, a user’s goal may be “I would like to decide on a way to organise my growing book collection by visiting the new IKEA website”. There are multiple possible user tasks involved in achieving this one goal. One could be: “I will search for book cases on the new IKEA website”, another could be: “I will browse living room furniture on the new IKEA website”. Measuring the task efficiency of one may be ignoring the task efficiency of the other. This is particularly scary when usability (user) testing is conducted for task efficiency by using pre-defined ‘leading’ user tasks.

I am not sure if there is a single key to to software usability. I believe that usability of software, as with most things in life, is ‘contextual’. This is why I personally like the ISO 9241-11 definition of usability being:

“”The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.””

(I tend to break effectiveness down even further into two components: ‘completeness’ and ‘accuracy’.)

With the three defined aspects of usability, it is then important that these are prioritised relevant to the context in which the software is used, by its specified users.

For example, user efficiency may be the most important aspect for software used by bank tellers processing bank deposits, as banks want to minimise staffing levels and queues for customers. On the other hand, software for researching criminal histories being used by detectives on a murder case may have a requirement for high levels of user effectiveness. This is because the detectives need to be very accurate when using this software, as they are publicly accountable for their actions.

This ISO definition also takes into consideration that there are different types of users who have different types of skills in different contexts. A bank teller may be using software whilst serving an irate customer (who has lined up for too long) and will therefore be likely to have a lower tolerance threshold when using the software.

Very much like what I see here, and while I have some questions/response I would like to see more on what ‘efficiency’ is perceived as in your domain.

Linux needs a lot more work to catch up with MS tools in terms of ‘developer productivity’ (not build or versioning systems, I am aware they are the leader just as Java always was and is copied all over in N* rather than J* naming convention:), but it is on a better path than ever before. The Tim Lee comment says it all, and most of it is due to lock-in and sheer scale and business practices and what not.

And not that I am against productivity (after all great economists always tout it, and I am not one), but performance designs are some of the most brilliant works I have ever come across in last 20 years or so of intermittent following.

I also have difficulty accepting complex or large software projects are the only succesful work out there. However, I do appreciate that success is most likely to come from ‘community’ rather than individual.

[…] Ultimately, Bazaar rocks because of 2 main reasons. Firstly, it has a very active community behind it lead by some very smart people. Secondly, it started with the goal of being a tool people will love to use, so user-centered design followed. Next week, I’ll be looking at usability more closely: It Takes a Community to Raise Great Software. […]