BoS digest: video of Steve Krug on the least you can do about usability

Tim Lister, the author of Peopleware, spent a couple of days at Red Gate last week. I was slightly nervous - Tim’s last visit culminated in my group haranguing by thirty developers, testers, designers and technical authors following Tim’s excellent, concise and witty summary of all Red Gate’s - and, implicitly, my - failings.

It was worth it though. In the year and a half since Tim was last here we’ve implemented many of his recommendations. We got rid of project team bonuses, improved our project approval process and hired six more people to join our user experience team. Sure, we’re not perfect, but we’re a lot better than last year.

One thing that Tim noticed was how articulate and passionate our development team is. According to Tim,

"Software development is about informed argument. Arguing about what the product is, and how exactly it’s going to do it, is fundamental to building a product that people will pay real money for."

But although articulateness and passion produce better quality arguments, and hence better software, they also have a bastard cousin: obstinacy. As Tim said,

"Obstinacy is “I know the best about everything”, which comes from a child’s view of the world. Being obstinate is friction. It’s wasted energy. We need a definition of what is valid debate and what is obstinacy: the debate has to come to closure. You win some, you lose some, but you need to move on."

Tim also made the excellent point that individual team members, especially developers, need to de-optimize themselves to optimize the team. The aim isn’t to get developers developing in the most efficient way: it’s to deliver a complete product. An individual developer might need to sacrifice some personal productivity for the benefit of the overall project. He might need to change the way he works, or throw away some code, or go off and do something else for a bit, so a tester can test sooner or better and the project can run quicker.

Which leads me to this week’s question of the week. If there was one thing you could change about the way you write software, what would it be? And what’s stopping you? $20 for the best answer. Post here.

Last week’s QOTW was “Why do, or why don’t you, use Twitter”. Of the 25 replies, I think Adriana Iordan’s deserves the $20 prize.

On the forums, Michael P asks for advice on pitching to bloggers. If you’ve got some advice for Michael, or a story about what you’ve tried worked or failed, then post it on the forums.

I hope you can join Steve Johnson and me for an online chat about product management on Friday. Steve is an expert - he’s taught thousands of people about product management, and presented at the Business of Software conference two years running. You can sign up here.

The video of Steve Krug’s talk at Business of Software 2008 is now online. Steve has a theory that our lives are full of things we know we should do, but don’t really want to do: brushing our teeth, doing our laundry and usability testing, for example. So what is the least you can get away with? It turns that you can get extraordinary results with a minimum of input. For usability testing, anyway. Watch Steve’s video to find out more.

I’m hoping to announce the date and location for Business of Software 2009 very shortly. If you want to be the first to know, then follow me on twitter.

Interested in building long-term, profitable, sustainable software businesses? Then join the Business of Software social network.

Subscribe to the RSS feed

Comments

[Steve Cholerton]

'Tim also made the excellent point that individual team members, especially developers, need to de-optimize themselves to optimize the team. The aim isn’t to get developers developing in the most efficient way: it’s to deliver a complete product. An individual developer might need to sacrifice some personal productivity for the benefit of the overall project'

This is an excellent point. A few years ago I discovered the author Eli Goldratt and his books. He makes exactly this point when talking about manufacturing systems. It's not about local optimums, it's about the throughput of the whole process.

I definitely recommend his books. Very very good, and written as stories rather than plain text books. - Steve