Archive for February, 2010|Monthly archive page

Seeing the Forest for the Trees, or, Seeing the Trees for the Forest

When I was younger, I used to paint quite a bit.  There were many times when I would be gritting my teeth, feeling the tension in my neck, frustrated at being unable to get something just right or not being able to see what I was missing.  I would have to walk away for a couple of hours, days, weeks, or months (in the case of the one behind my bed, years).  When I would come back and look at it with a fresh mind, it was so easy to see what was wrong.  Bad proportions, not enough shadow, need for detail in more areas, whatever.  But I would pretty much always be able to see it the instant I set eyes on it when I came back to it.

This system that we’ve been building since June is in a very intense phase of testing, and there have been times when I spent a full day beating it up.  I wouldn’t be able to see anything new at all, but would know the system was not bug-free.  Intensely frustrated, I refused to give up because of the time limit imposed.

This was the wrong decision.

By taking just a few minutes and walking away, I was able to come back a little more clear-headed and calm and get a fresh eye on things.  It can be the same way when you are writing user stories; you think about something for so long that you feel like you have everything, then when you go to put it on the board you see that a piece of acceptance criteria is blatantly missing.  Or when you’re developing something and you miss something really obvious because you’re so mired in the details.

This could be a post promoting pomodoro, it could be promoting an iterative process, I don’t really know what it is.  I guess what I’m saying is that sometimes you need to make sure that when you’re creating something, it’s good to step away and come back with a fresh eye. 

Take 5 and get a little brain massage and come back to it; “wasting” five minutes to  recharge/reset your brain is better than thrashing for an hour and ending up completely frustrated and with holes in your project.

Building a Safety Net

After our alpha test, we had a round table discussion with the involved developers, the alpha testers, and the rest of the product owner-y type people.  They talked about what they liked, disliked, general wrap-up business.  One of the greatest compliments we received was from a seasoned pathologist who has seen plenty of other lab information systems; what he said was:

One thing I love about this system is it made me feel like I couldn’t get hurt.

That is a thing to strive for.

Pathologists can really get hurt if a system is not built well.  Their patients can get hurt.  Our patients can get hurt.  We built in so many safety nets so that users do not have to worry about screwing up.  Users should be concerned with the task at hand, not with worrying about how software will react or if something is going to get messed up and affect patient care.  It was an honor that he said this to us, and I am proud of our system for making him feel completely comfortable entrusting people’s lives to our software.

Medical software aside, I think all software should make you feel like this.  You should never feel painted into a corner or like you can’t go back and change something.  Users should always feel safe and comfortable using your software, and by your team doing plenty of thinking up front, users will not have to concern themselves with it.  By building software as such, you are allowing them to focus on their workflow and tasks without having to worry about whether or not they will get hurt or hurt someone else.

Think about how they will unconsciously or consciously screw up, and make sure they can’t.  Or if they can, make sure they are damn aware of it and able to fix their error without a whole lot of extra steps.  No one should have to suffer anxiety when using software, and we all do far too often. 

This is something we can fix.

My First Alpha Test, or, The Importance of User Awareness, or, Gaining Perspective.

Two weeks ago we held an alpha test of the product we have been working on since June.  While I knew it would be an eye-opener to see people actually using the product, I didn’t know just how much of one.

I asked one of the developers, Ed Taupier, to give me some of his thoughts on how the alpha test opened his mind, changed his point of view. 

“Probably the most important outcome of the alpha testing, for me, was to gain an understanding of how the targeted clients would react and use the software we had built.  Or course I had my own opinions about which part of the software i really liked or disliked, was proud of or not.  My perspective is heavily "programmer" based though, which means the technological aspects effect my view.  This is not the perspective of the users, however.  
    It was extremely interesting to see what the testers found most interesting, valuable, useful and (yes) terrible.  Witnessing and gaining an understanding of their perspective impacted me a great deal.  It emphasized how important maintaining a "user" awareness and perspective is to a project’s ultimate success.  This has been one of the more difficult aspects of software development for me in the past.  Now i have a better understanding of how users in general, and our client base specifically,  view software.  This will greatly enhance my ability to contribute to and affect the success of projects in the future.”

Very well said. 

I’ve actually been reading that bolded quote for about 20 minutes, trying to expound upon it, but it’s perfect.  Being constantly aware of the fact that someone is going to use what you are building is important (and sometimes hard).  I mean, it’s my job to be the user, to tell developers what to make…it’s harder for developers to get in that user mindset.  When I watched Ed and another developer during the alpha test, taking in every mouse click and every question and every…everything from the testers, I could see that their perspective had really changed.  It was beautiful to watch them watch the fruits of their labor being used.  My demands for checkboxes to be in consistent locations and for filters to exhibit certain behaviors were no longer major annoyances and nitpicking; the developers could clearly see what the testers struggled with and where they had questions, and they knew exactly what needed to be done.

Since the alpha test, the quality of the code has gone up, I’ve not heard one peep of bitching about having to do something, and there is very clearly a lot more thought going into the code that is produced.

It is important to keep in mind not just what feature you are building at the moment, but how someone will be using it and how it relates to the rest of the system.  Things can get really frustrating, especially if people are being demanding, but as long as you are able to get out of a developer mindset for at least long enough to consider what is being asked for and think about your customers using the software, it should be easier to see.

I wrote a post on a similar note a while ago, and I got a lot of flack for it.  I hope this post makes my previous words seem less harsh, and more well-intentioned.