Archive for September, 2009|Monthly archive page

Like the Back of My Hand: Doing What You Know…Everywhere, or, Life Imitates Software

A while ago I wanted to start up an Etsy shop.  I had no idea what to do, as I am quite crafty but equally unfocused.  People told me “just do what you know.”  So I started making Beatles shot glasses and pint glasses (in case you don’t know me, I am disturbingly into The Beatles.  Thanks to all of you who do know me for putting up with it).  They sold pretty well and I had a great time making them.  It was easy.

When I wanted to start blogging, I had no idea what to write about.  People told me “just write what you know.”  Had to think about that one for a while before the first few blogs came out.  But the next ones were easy; usability issues are everywhere and even jokes made me think about software process issues.  All I had to do was look around and observe things and the answers were in front of me, because I knew them.  It was easy.

The point I’m getting at here is that these things were easy once I realized all I had to do was what I knew, and what I do on a daily basis.

The real point I’m getting at here is that this is obvious.  Doing what you know is easy.  Doing what you do on a daily basis is easy.  What reason is there not to adapt your life processes to your software processes?  Things that are second nature to you should present few problems in being applied to your software (though your team may take some convincing).  Really, it’s just a good way to figure out what is wrong on your team (or in your life) and figure out how easy it is to fix it.  Here is a small quiz about life and software development:

Scenario 1: You and your special someone have a miscommunication.  Do you:

a) Let it fester until the resentment has built up so much between you that you’re doing that “get the jelly, twat” joke in the middle of Publix but it’s even less funny than when Dane Cook did it

b) Talk it out until you are on the same page so that there is no tension and so that you can better handle similar situations in the future

If you said A, yer doin it wrong.  In the sense of literal communication, you need to be sure to discuss issues to keep the pair relationship and team relationship healthy.  Having a lot of tension between team mates can create not only a very unpleasant environment (for everyone), but will produce shittier code and probably mess up your velocity/cycle time (just because you’re is not functioning well as a team).  Keep your relationships healthy with communication (see: some other blog I wrote).  In the sense of letting things fester, ignoring problems or not resolving them right away is a fast way to fail.  Your system will get buggier and worse the longer you go without fixing bugs as they come up.  Fix problems as problems occur to prevent this kind of crap from happening.  If you said B, congratulations!; that was the right answer.  When pairing, dating, or even just working as a team, I find that JIT retrospectives are the way to go.  To me this doesn’t necessarily mean sit down after each feature is developed and deeply discuss every good and bad thing that has happened, but it does mean that during a weekly demo (or whatever form of that you do) you should talk about how things are going.  Iteratively handling situations will help you to grow closer rather than apart, and you will learn (in either scenario) much faster how to handle the situation as it arises and improve upon it from there.  We used scrum for a while and the daily stand-ups kind of handled this, but we really didn’t need to do it daily; it just ended up being wasteful.  Handling issues just in time at our weekly demos has proven immensely helpful to us; I recommend giving it a shot.  The big retrospective at the end still has value, but you might not even need it if you’re handling things as they come.

Scenario 2: You and your sweetie are planning a vacation to a secret remote tropical location.  Do you:

a) Plan out every detail far in advance and set a very strict itinerary

b) Keep a list of the items you want to do and set general ideas about when to do them

Why does A fail?  Rain.  Exhaustion from climbing a mountain the prior day.  Being hung over from a dastardly amount of rumrunners.  Whatever.  There are too many outside variables that you won’t know if you plan too far in advance.  Option B allows for plenty of change, and a more relaxing time.  Sure, you may need to set some things in stone if they are only available at certain times/on certain days, but for the most part keeping it easy will afford you a better vacation.  Change is a constant, so it is really the only thing you can plan for and ensure that those plans will work out.  JIT planning of your activities will ensure that you are always doing what you want to do next rather than what has been decided as your next item; JIT planning of your stories and priorities will allow room for change and make sure that the next thing you’re working on is the next actual priority.  Now, here I am kind of a liar, because I sure do like to make a good itinerary if the occasion should arise.  But I’ve fallen prey to all of the above downfalls I listed for A (especially the hangover), and also I’ve had great opportunities come up while I was on vacation that bumped other things off the list.  And they were worth it.  So I’m going to try out approach B for the next super secret remote island getaway I plan because I know it will work.  Because it works on my team.  These things, they go both ways.  Get it?

I could probably go on with more scenarios but a) your eyes might glaze over b) I think this is a good start.  Think about things you do and the way you effectively handle situations in your everyday life.  How can you apply these to the way you work, your processes, your team environment in general?  Are you working in a way that is contrary to the way you naturally work?  If so, why?  Start paying attention to things like this and see if you can find ways to improve by doing more of the same, but in a different area of your life.  All you have to do is look around and observe things and the answers are in front of you, because you know them.

Usability: Your Mom Loves It, or, I Friggin’ Hate My Car Stereo

I friggin’ hate my car stereo.

I installed it about two months ago and have just been hoping that it will get better/easier/I will magically figure it out, but no.  It makes me angry almost every day.

What’s that you say?  Read the manual?  Hell no.

I hate you.

I read through some parts, things that I needed to know immediately, but I don’t want to read it.  Most people don’t want to read it.  How many of you read the manual for each new product that you get/new software that you use?  Do you read a 60-page manual, or do you poke around with something until you’ve figured out how to use it?  Well, guess what.  Your users probably do that too.

If you’re anything like me, you poke around and swear and complain until you’ve figured it out, and then triumphantly give the bird to the technology that you have made your bitch.  I have given the bird to my car stereo several times already, but never triumphantly.  Here are some reasons why:

1) It scrolls a title across so you can read the full thing.  Well, that’s great, but it can fit probably 16 or 17 characters on the display, and it scrolls every name.  So when the song Milk by Kings of Leon comes on, it will scroll that title.  Four characters.  (note: This was the first time I noticed this particular annoyance, and what a prime example.  FOUR CHARACTERS.  Are you kidding me?!)  This is an easy piece of acceptance criteria that was missed.

As a Pioneer car stereo owner I need text to scroll when a song comes on so that I can see the full body of text.

– If text is <n characters do not scroll.

Ta-da.  That was hard.

With just a little more attention to detail and developer thought this would not annoy me EVERY DAY.  Developers should be thinking about multiple scenarios and general usability as they build new software.  This was simply an oversight and a lack of thought.

2) You can only control the iPod through the stereo itself, not through the iPod.  Well, you can if you have any models except X and Y (I have Y…I don’t remember exactly what it is, whatever generation video yadda).  A) Why make it compatible with every iPod and iPhone except the one that I use (and one other one)? B) I have 4800 songs on my iPod.  In order to use the stereo to find the track I want I have to go through EVERY ARTIST.  And the scroll wheel on the stereo?  Not so fast.  It is easier to unplug the iPod and find the item on there and play it, then hook it up.

I shouldn’t have to figure out alternate solutions to play my music.  I shouldn’t have to unplug my iPod every time.  The solution should present itself.

3) There is a way to shuffle the artist but you have to, like, uncover a staff and put it in just the right spot and the light has to pass through the glass and indicate where the buttons are to make that functionality happen.  I don’t know how to do it.  The times I have made it happen have been purely serendipitous.  I do know that every time I try to do it, I shuffle all 4800 songs and sometimes it sets my iPod itself to “shuffle artist” so the next time I try to listen to an album it plays it in random order.  Changing settings on my iPod without my permission?  That’s a paddlin’.  The functionality should be limited to the stereo itself.  Now, when I listen to my iPod on my sounddock or with headphones later, I will have to go into my Settings and change it, even though I never elected for the change to happen in the first place.  Poor.  Usability.

So, let me get to the point (finally).

I am a fairly typical user of this system.  Maybe I have a leg up because I have a pretty good handle on technology, but in general I am someone who listens to music in my car and can press buttons.  This shouldn’t be so hard.  Especially for someone (fairly) adept at using electronic devices.

Usability is a really key part of good software.  The book “The Design of Everyday Things” by Donald Norman is one of the greatest books you can read as someone interested in making quality software.  One of my favorite points that it makes is that users should not notice design.  If a user notices design, it’s generally because they have been given cause to because they can’t figure out how to do something.  Your design should be very intuitive and friendly to users; they should be able to just breeze through it without thinking.  If you have to put a lot of labels or instructions on something, you’re probably doing it wrong.  Don’t get me wrong, often some type of directive is necessary (working in medical software, it’s hard to get around sometimes).  However your system/site/app should be pretty damned user-friendly.

The keys to good usability really boil down to just a few things:

1) Developers need to put thought into the use cases of the software and multiple scenarios for which it will be used.  Think about the value that you are providing to a user and how you can make that even better.  Kaizen that shit.  Put a lot of thought into what you are making so your users don’t have to put any thought into using it.

2) Attention to detail is critical.  Think about anything you buy.  Handmade things in particular.  You want the one that looks the best, don’t you?  Well, maybe you want the quirkiest because you’re the hippest hipster of the bunch, but you get the idea.  Quality is absolutely necessary if you want to sell a product and attention to detail is a cornerstone of quality.  Yes, of course it’s important to hit the big points and get the big features, but something with a lot of great features that misses a lot of small things and is wholly unusable is not a product that people want to buy.  I consider any lack of attention to detail to be a bug, whether it is an actual defect or not.  Ignorance is a defect.

3) Make it intuitive.  If you’re developing iteratively (which you should be), demo it to your users.  Can they figure it out?  How many questions have they asked you about what something does?  Go from there.  When I design things I like to try to think about my mom using them.  She doesn’t know what the internet is, so it’s really an extreme example, but in general I try to think about people who don’t have a lot of technical prowess.  A lot of our software is designed for doctor’s offices, and an awful lot of people in these offices are averse to new technology and in general using computers/software.  What I need to do is design something that will be so easy to use that it a) won’t completely change their workflow/add time to their daily tasks b) will be enjoyable to use.  That is how you should make all of your software.

There are a million things to say about usability so this is likely the first in a series of posts (mostly this one is just a rant about that damned stereo), but I welcome any input or questions for future posts in the comments.