Rocket Science

So, one of the things I’ve been doing is testing out stuff that we could be doing at my job at OEIT–for my team, our office and the university. I’m struck by…why aren’t we doing this? (And yes there’s a back story.)

The final set up is really quite sweet. A member of the university goes to https://blogs.lincoln.ac.uk for the first time and logs in with their usual credentials. The first time they login, they are signed up. That’s it. No sign up page needed. It’s as if they were already a member of the social network, which, being members of the university, they are of course. From there, they see the BuddyPress home pages, can join groups, change their profiles and, when they’re ready, create or join a blog.

Winn, J. (2009, February 17). BuddyPress: A university’s social network. Retrieved June 18, 2009 from ../learninglab/joss Web site: http://joss.blogs.lincoln.ac.uk/2009/02/17/buddypress-a-universitys-social-network/

Aside: I’m not sure I really like the BuddyPress user interface nor how much WordPress MU seems to lag behind the regular WordPress releases, but I do really like the notion of social network, collaboration and publishing platform.

Thanks to Brian Lamb’s post for pointing this out.

Kathy Sierra, of O’Reilly’s Head First Series, presented 10 tricks to improve the user experience during her opening keynote at the 2009 NMC Summer Conference. Kathy was a very entertaining speaker, and had a number of useful messages.

1. Focus on what the user does, not what you do. For example, instead of focusing on developing a better camera (product), focus on creating a better photographer (user).
2. Give the user superpowers quickly. Users are often discouraged if they’re not “experts” or have problems using products, help them develop practical skills quickly to give them a sense of power.
3. Make the user smarter.
4. *Don’t focus on [x], ask what [x] is a subset of… What’s the bigger thing/idea that your product is part of? For example, don’t blog about a camera (product), but blog about photography.
5. Shrink the 10,000 hours. Create a culture of practice. Instead of requiring or expecting 10,000 hours of experience for expertise, design products to help the user get better/good in less time.
6. Make your product reflect their feelings. How you make them feel about themselves drives how they feel about you.
7. *Create a culture of support. [Policies and scaffolding are important.] Convert people from askers to answerers…if users help other users, they’ll feel better about their mastery of the product, and they’ll help you out by reducing company-provided support needs.
8. Do not insist on “inclusivity”. You experienced users will “talk differently”, embrace that. [I'm not sure if this is really good or not, or if I just missed something.]
9. *Make the right thing easy, wrong thing difficult. Amen, I’d add an addendum “simplicity, simplicity, simplicity”.
10. *Total immersion jams. To learn a product, to get a project done, and so on. Frequency matters: spend 16 hours over two days, instead of spending 16 hours over two months.

For OEIT, I think the asterisked items are particularly important.

Also, I think the items on Kathy Sierra’s list are very complementary to my recent post on Messaging.

I won’t be the first, nor the last, to say that the movie industry really needs to figure out distribution of high-quality digital movies to consumers. As it stands now, consumers are hampered by an odd mixture of sales practice that governs when, how and in what format movies are available. Basically, I want to be able to get movies when, where and how I want them–and I’m willing to pay a reasonable cost.

The nature of technology has reduced the cost of distribution from a few dollars (to press and package a movie on DVD) to nearly nothing (in bandwidth to distribute a movie over the Web).

(Ok that’s a gross over-simplification since DVD distribution includes storage, delivery, shelf space, etc. But that’s not really what I think I need to pay for. I’m not your average consumer, I buy what I want based on interest, knowledge of what’s been shown in theaters and maybe a little Web-research, not just what’s presented to me at a store or on a shelf. Having to go to a store and walk the aisle to browse for a movie (to rent or buy) is not something I really do–it’s rather arcane these days. In fact, it’s why companies like Blockbuster are having problems. Also I used what I perceive as the costs for DVD duplication and not Blu-Ray which has higher manufacturing costs for which I don’t have an order of magnitude estimate.)

So, how do I want to purchase/rent movies? It’s a little complicated. Maybe…

Read more…

I was reading an interview in Computerworld with Christophe Louvion (see page 2), the developer of Scrum programming, where he talked about “agile” programming and teams.

A couple points he made really struck a chord with me.

Programming Practices

Has agile become so mainstream that it’s become a trendy, meaningless buzzword?

The term agile is being used by [some] people to justify poor programming practices such as cowboy coding.

“We don’t have to write documentation; we’re doing agile,” they’ll say. Like with everything else, people are bending the rules to accommodate their personal preferences.

I’ve lived this. I won’t name names or projects, but I definitely think Christophe’s opinion has merit. I’ve been on a project where “agile programming” was “used”. Or at least elements of it like team programming and rapid iteration. However this technique was technologist-/programmer-driven, not customer driven. And therein lay the problem. The technique seemed to be as much a means of removing the programmer from good communication and customer interaction, as a means of developing the product. Unfortunately for the project, it took me a long time, working a number of different methods, to try and address the issues at hand. I think we had some limited success in the near term, but I can’t help but wonder what we did to the long term potential of the project.

The phrase “cowboy coding” also struck home. “Cowboy coding” is described by Kent Beck in another Computerworld article (see page 2) as:

In cowboy coding, you go off and you do heroic stuff, and you feel good about yourself because you figure there’s nobody else in the world that could have possibly pulled out something like this.

I’ll agree that there is a time and place for heroics and all that. But, when every release seems to rely on heroics to get it out the door, there’s something wrong.

And for the love of pete, document what you’re doing. Documentation’s not fun, I know I’ve done it. But, there are strong merits for doing it. (One of these days I’ll have to write my story about developing a video player for my Master’s project.)

Teams

Christophe goes on to say:

There is a good quote from the chairman of Toyota. Someone asked him, “What is Toyota’s advantage?” He replied, “It is our ability to get normal people to do outstanding things. Other companies try to hire outstanding people to do normal things.”

I have a corollary to this thought…we (I) try to hire outstanding people to do outstanding things. I’ve been blessed to work with some of the brightest people around. I’d like to believe that by hiring outstanding people, we’ve been able to do some pretty remarkable things.

It’s also probably true, that the chairman of Toyota was also cautioning about expecting outstanding people to only do “normal things”. Everyone at some time has to do “normal things”, and it’s definitely something to be concerned with if they’re expected to do outstanding as the norm. I think this is where it’s my job (I’ve been the manager) to enable the individuals and the teams to do the outstanding work, while still making sure all the “normal things” gets done.

Another thought comes to mind–definitely hire the person not the skills. Skills can be taught or learned, the intangibles that define the person cannot. Perhaps I’ve been extremely lucky in each of my jobs, but in many cases we’ve been able to hire the right person, and as a result have had some outstanding teams that did some outstanding work.