Benjamin Hysell – Software, Projects, and People Rotating Header Image

November, 2009:

November Reading List

Nov 24th, 2009
by Benjamin Hysell.
Comments are off for this post

Just last night I finished reading Zen and the Art of Motorcycle Maintenance, and decided it was high time to update My Bookshelf with what I’ve been reading lately.

Zen and the Art of Motorcycle Maintenance is not a breezy read, nor, sadly, does it have much to do with motorcycles or Zen.  I should have paid more attention to the authors note, which I’ve included here:

What follows is based on actual occurrences.  Although much has been changed for rhetorical purposes, it must be regarded in its essence as fact.  However, it should in no way be associated with that great body of factual information relating to orthodox Zen Buddhist practice.  It’s not very factual on motorcycles either.

That being said you will not be disappointed if you pick this book up.

Zen and the Art of Motorcycle Maintenance: An Inquiry into Values by Robert M. Pirsig

I’ve tried to summarize this book for a couple of people, and have come up woefully short in every attempt. A few of the key points that I did extract from Zen are:

  • Where do ideas come from?
  • What is Quality? Is it subjective, objective, or something else?
  • Does our system of education really teach people anything, or are people rewarded for actually not learning and regurgitating?

However, the one idea that I’ve run into a few different times, in a few different texts can best be summed up by a webcomic from xkcd:

Dad, where is Grandpa now?
Deadeye Dick: A Novel by Kurt Connegut

I have thoroughly enjoyed every Vonnegut book I have picked up thus far, and Deadeye Dick did not disappoint. I enjoy Vonnegut’s pacing, sense of humor, and overall style. In true Vonnegut style, around 50 pages in he tells you how the book is going to end…I always may know the destination, but I never know how he is going to take me there.

If you are also working your way through Vonnegut’s collective works do not skip past Deadeye Dick.
Rigged: The True Story of an Ivy League Kid Who Changed the World of Oil, from Wall Street to Dubai by Ben Mezrich

I have a thing with people named ‘Ben’…I’m sure its mostly me and not them, but I have a thing.

I have yet to met another person named ‘Ben’ that I liked.

It begs to be asked, if I ran into myself would I like me?

Think about the recursive loop that little meeting could spin into…

Or, or pickup Rigged by Ben Mezrich. This Ben might be one of the few I might enjoy if I were to ever meet him in real life.

You may or may not know Mezrich from his more widely known book 21: Bringing Down the House – Movie Tie-In: The Inside Story of Six M.I.T. Students Who Took Vegas for Millions.

::…if you haven’t had the chance to enjoy Bringing Down the House, Mezrich’s first widely known outing, skip the movie they based off his book and grab yourself an excellent Vegas thriller.::

Mezrich brings his signature storytelling style to his latest outing. Mezrich starts with an Ivy league grad seeking direction in his life and places him in the middle of dark underground world full of colorful people and larger than life events.

When I pickup a Mezrich book by this point I know the formula, I just don’t know what he will plug in for characters, locations, and main ‘event’. In Rigged we start with a recent Harvard Business School graduate, graduating into one of the worst job market for MBAs, the fall 2002. Take said graduate and introduce him to a powerful person, head of the NYMEX, inject a little oil trading, and let the fun commence!

Its not a bad formula…I’ve grown to enjoy it.

Auto Fail

Nov 19th, 2009
by Benjamin Hysell.
Comments are off for this post

Lately I’ve been pondering, “Why is it that most people design the user interface last?”

It would seem, to me at least, if one were to design a product for the mass market, one would focus a lot of time and energy on how that product would be seen by that market.  What will it look like, how will it function in peoples’ hands, how will people interact with it.

Seems logical, if you want people to like your product they need to enjoy using it.  Spend a lot of time making that product enjoyable to use and people will love you.  If on the other hand, you make using your product painful, awkward, and hard people will tend to shy away from using your wares, and you can bet they will tell their friends about their horrible experience.

I was inspired for this posting on a recent trip to San Diego where we rented a nice economy car for the trip.  I snapped a few pictures of the car’s “user interface,” or inside, to share with you some of the pain I experienced on our trip.

I give you, auto fail.

Figure 1, the steering wheel from our rental car.

Steering Wheel

Figure 1. Steering Wheel on Our Rental Car

Seems to hold the function of most steering wheels, its round, it was fairly comfortable, as so much it wasn’t wrapped in barbed wire, and when I turned the steering wheel the car also turned…so far so good.

Let’s take a closer look at the two controls they deemed necessary to include on the left hand side of the steering wheel.

IMG_0297

Figure 2. Up-close and Personal With the Steering Wheel

Two buttons are included in Figure 2, they must be important, right?  I mean someone took the time to make a mold of the steering wheel and cut out those two buttons, then run wire all the way up the steering column to connect to these two very important buttons.

These two buttons control:

  • The information that is displayed on the dash, mpg, average speed, distance to empty.
  • A return button.  Honestly, I’m not sure what it actually returned from.

In most every car I have ever driven these buttons are replaced by a stalk that comes out of the dashboard, or they are on the end of the turn signal.  They are never given prominence of being placed on the steering wheel where so many more important buttons could go, like radio controls, cruise control, anything that could actually help me while I was driving!

And what type of great information did these two buttons deliver?

IMG_0299

Figure 3. Information Display on the Dash

You get the coolant temperature…

What am I going to do with the coolant temperature?  Is it going to change the way I am driving?  Should I shut off the AC?  Should I change a tire?  I have no idea what this piece of information on my dash serves me as I drive.

So far I have two buttons on this car that take up some prominent car real-estate, strike one.  On top of that these buttons show me information I can’t even do anything with, strike two.

Strike three comes in the form of the emergency brake.

Emergency Brake Usable

Figure 4.  The Emergency Brake

At first blush the emergency brake looks perfectly functional.  Figure 4 was taken with the armrest up.  Figure 5 is how the emergency brake is normally in the car.

IMG_0306

Figure 5.  Normal View of the Emergency Brake.

The emergency brake is completely covered by the armrest.  Every time I park I need to lift the arm rest to use the emergency brake.  Every time I want to start driving again I have to lower the arm rest to make it functional.  A fairly simple task, parking and then driving, complicated by constantly having to raise and then lower the arm rest to get to the piece of equipment I want to use.

If I owned this car it would drive me insane, (no pun intended), every time I went to use the car.

Needless to say I had a horrible experience driving this car and I’ve now told all my friends about it.

Breaking Down the Game Film – Micro Code Reviews

Nov 17th, 2009
by Benjamin Hysell.
Comments are off for this post

“Breaking Down the Game Film” is a term commonly used to analyze tape from an already played sports game to dissect what went right and what went wrong.  In this series I’ll be taking published articles from around the web and break them down.

Topic: Micro Code Reviews

Article: “The Joy of Code Reviews”

Author: Tom Hollander

Link: http://blogs.msdn.com/tomholl/archive/2009/01/06/the-joy-of-code-reviews.aspx

Short Summary:  Full code reviews are done too infrequently, and take too much time to complete to be done with any real regularity.  Micro code reviews, performed before every check-in, provide you and your project all the benefits of a full fledged code review, but also facilitate knowledge transfer between team members, an avenue to provide mentoring, and a chance for your team to “show off” to one another that cool new algorithm they have been working on.  All in 15 minutes or less!

Analysis:

When was the last time you reviewed the whole codebase for your project?  Stem to stern?  I know, I know, who has the time.  Everyday the codebase gets larger and larger, and each one of your team members becomes more and more specialized in whatever it is they are working on day in and day out.  What happens if one day George walks in and goes, “I’m off to Alaska to follow my one true calling.  Being a software developer is nice and all but I wanted to be… a lumberjack!”

::Deep down you know he’s a lumberjack, and he’s ok.  He likely will sleep all night and work all day, but I digress…::

George is gone.  When was the last time anyone was looking at his code?  Who on your team knows how his really cool, yet very complex, algorithm runs?  Sure it all works, but who last put eyes on his code to try to and understand it?

If I know your team, and I likely don’t, but I’ll assume I know them, no one has looked at his work in a while.  Why would they?  George’s code worked, all of his tests passed, who has the time to review working code?

Your project has just suffered a major brain drain, and you don’t have a plan on how to recover quickly.

Tom’s article, “The Joy of Code Reviews”, provides some great reasons for you and your team to adopt what I’ll call micro code reviews.  A micro code review works like this:

  • Before every check-in to source control George grabs a fellow team member, Stan, and they review all the changes that are about to be committed to source control.
  • In Tom’s article he states these reviews often last 15 minutes, some much shorter, some a little longer.  Fifteen minutes seems just about right for a couple of programmers to review a bug fix or feature enhancement and has been the typical amount of time my team and I have taken for our own micro code reviews.
  • After George and Stan have reviewed the code, ensured the unit tests pass, and then check the code into source control.

Pretty simple and straight forward; spend 15 minutes before every check-in, or 30 minutes billed to your whole project, to get a second set of eyes on the code that is getting into your source tree.  On top of that:

  • In his article Tom calls out one of the great benefits in doing these reviews is the mentoring that can take place between two developers.  George has a chance to show Stan the new functionality he has implemented and possibly a new way to write code, debug, or write tests.  As Stan is exposed to George’s style he may pick up a tip or trick just watching him work.
  • I’ve personally seen George improve his ability to explain complex thoughts and algorithms to Stan.  Oftentimes we work in isolation, only explaining things to ourselves.  By sharing with Stan and forcing himself to verbally explain things George has a chance to work on his presentation skills as he breaks down a complex problem to Stan.
  • Micro code reviews provide a chance for a team to feel more like a team as they work directly with one another.  I feel my team has gelled together a little more with these mini interactions that take place during these micro code reviews.
  • One might think developers would be resistant to these micro code reviews, however I found when I argued one could “show off” that cool new thing they did everyone seemed to get on board after doing a few code reviews.  Software developers love to have the admiration of their peers, give them a stage and most of them will step up and gladly perform.

I’ve adopted micro code reviews for my team and have had some excellent results.  Team members are grabbing one another when before new code is committed to the system.  Spirited debate takes place between the developers while reviewing the code, and learning is going on as each one learns from one another.  For us it has been a huge win win.

So when George answers his primal calling to be a lumberjack…

:: He cuts down trees.

He eats his lunch.

He goes to the lavatory.

On Wednesdays he goes shopping

And has buttered scones for tea.

I’m done, I’m done, I swear.  No more Monty Python for this post…::

You and your project will be prepared.

Tools in the Toolbox – Personas

Nov 5th, 2009
by Benjamin Hysell.
Comments are off for this post

“Tools in the Toolbox” is a series of posts on development and design tools I use on a daily basis.

I am a huge fan of Alan Cooper and personas…huge fan.  I have written at length about him and his techniques here, http://benjaminhysell.com/archive/2009/02/alan-cooper/.  My goal in this article is not to cover the basics; other blogs and books cover the basics of personas.  Rather, I hope to cover why I use personas, and why I have embraced them.

So, why do I love talking about personas and using them for quoting, specifications, and development work?

Fear.

::No wait, I’ve used ‘Fear’ already as a motivator for using Test Driven Development here: http://benjaminhysell.com/archive/2009/08/tools-in-the-toolbox-test-driven-development/.   I can’t just keep throwing around the same emotions…I had better come up with something different…::

Take two.

One reason.

I hate designing software for the person named “user”.

Think back to the last meeting you were in with your developers.

I have a great new idea for your blog website!  I think some of the users who use your website get lost in the technical jargon you use.  Let’s add a whole section that explains all of the technical terms that appear in your blog entries on the right hand side of each page.  That way when people come up against a new word they don’t know they can just glance to the right side and see a definition!

This actually isn’t a bad idea on the surface.  When my non-technical friends read my blog they may walk away with something more than just saying, “Wow, you write a lot of words!”

Then another developer chimes in…

Let’s build an iPhone app that links back to this blog!  Every time you publish a new article it’s automatically sent to the user’s iPhone, they get a notification that a new article is up and their phone will “ding” with a new article notification!

Again, not a bad idea…technically possible, would be kind of fun to implement, figure out the whole push notification framework.  Yes, that is a project I could lose myself in for a while, and in the end it would be sort of neat to have figured out all of that technology and to get something working.

Here is the rub, although each idea is fun, interesting, and very technically possible, neither one does anything for the core function of my blog.  Neither idea helps me write about managing people, software, and projects.  Nor is either idea squarely aimed at my core audience, other developers, project leads, and managers.

By using personas I can quickly and easily figure out if either idea is worth while exploring and implementing.

How you may ask?  Simple, I can quickly take every idea I have for my blog and ask myself,

If I had an iPhone app that notified John that I had published a new article would he use it?  Would it be worth the effort to publish such an app, and would John tell his friends about it?  Would John pay for an app like this?

Who is this John?  Good question…

Before going any further let me introduce you to John.

Name

  • John

Age

  • early 30s

Personality

  • Enjoys going out with his friends for weekly “Man Night” where many wings and beers are consumed
  • Plays sports year round, golf in the summer, hockey in the winter
  • Stays up to date on the latest technologies by reading whatever he can get his hands on

Skills

  • He is his families IT go to guy.
  • Loves learning new programming languages for the challenge of it
  • Enjoys manual labor after a long hard day of pushing pixels all over the computer screen.

Goals

  • Desire to own his own company some day
  • Realizes there is more to staying competitive in the market place than just knowing the latest software frameworks and architectures, hence he is reading outside of his field to learn how to do marketing and sales.
  • Aspires to have his own technical blog

Attitudes

  • Loves all forms of technology
  • Willing to be the first one to try new operating systems, development techniques, and be on the bleeding edge of all new technology.
  • Has a hard time stepping back from the computer at night since there is so much to continually learn.

John seems like a pretty good guy.  The sad part is he doesn’t exist except for me to test my blog topics, design decisions, and possible iPhone apps against to see if he would like them.

John is my sounding board.  John replaces all instances where I might go, “Would the user like this?”  Now all I ask is “Would John find this useful?  If I spend time on this would John tell his friends to check this out?”

Designing my blog towards a someone, a real defined someone, helps me figure out what I should do and keeps me focused on my core audience.  Remember that iPhone app?  John wouldn’t need it, John would be using RSS to keep up to date with my blog.

What about the jargon pane on the right hand side of the site?  John probably knows the jargon already, and if he doesn’t, i.e. its something new to him, he is going to be motivated enough to go look it up himself using Google.

I love writing for my wife,

::Thanks for proofing this for me!::

but if she comes across a term she doesn’t know she will likely use the surrounding paragraphs to figure it out or skip it all together.  I don’t care if she doesn’t get the whole article because she isn’t my core audience.

John just saved me hours of time implementing ideas for a “user” who isn’t going to read my blog.

For every project I sit down and define who my end users are for that project before I start.  Each one gets a name, age, personality, skills, goals, and attitudes creating a vivid image of the person I hope will be using my software.  Every decision I make, be it user interface or back end operation I ask,

Will John like this new feature?  Can he even use this new feature given his skills?  With his attitudes would he want to use this new feature?

I instantly know which features I should implement and which ones should go back to the drawing board.  Personas have become my strongest tool for designing software that people actually want to use.

Next time you get in an argument about an implementation detail or presentation issue ask out loud, “will our main user Steve actually like what I am creating for him?”

When a developer asks to implement this crazy new login procedure ask them, “Will Sally, our 75 year old grandmother who is our main user be able to figure this out?”

Bring real people into your development and you won’t be disappointed with what they tell you about your software or new idea.

Breaking Down the Game Film – Mission Statements

Nov 3rd, 2009
by Benjamin Hysell.
3 comments

“Breaking Down the Game Film” is a term commonly used to analyze tape from an already played sports game to dissect what went right and what went wrong.  In this series I’ll be taking published articles from around the web and break them down.

Topic: Mission Statements

Article: “How to Write a Mission Statement that Isn’t Dumb”

Link: http://www.fastcompany.com/magazine/140/do-something-wordplay.html

Short Summary:  The time used to generate most mission statements would be better spent burning $20s in the alley behind your office building.  Identify your company’s quantifiable goals and write a statement that will inspire people to rally behind those goals.

Analysis:

Quick!  What is your company’s mission statement?

Can you find it on your internal website?

Can you find it on their external customer facing website?

Ok, now that you have found it how do you feel?  Quick, one word!

I’ll spot you the word, let’s go with underwhelmed.

Now, compound that feeling with the thought of how many man-hours it took to produce that mission statement.

It’s ok if you are now openly weeping…let it out.  I know your company couldn’t buy you that brand new computer chair last year, they had to write a very bland statement that serves no purpose to you or your daily life.  Sure, the new computer chair would have been nice, but they really needed that sentence on their website.

Before reading this article I wouldn’t have given a company mission statement a second thought.  One of the tools I use, Microsoft Team Foundation Server, a task tracking and source control system, starts every project with a few pre-populated tasks.  One of those tasks is to write the project’s mission statement.  I normally skipped this step; I never saw any value to burning any calories on attempting to define the mission statement for an individual project.

However, after reading this article something clicked for me, making me reconsider the value of the mission statement.

Do you want to add a feature to the project?  Will that feature further project development?  Does it mesh with your mission statement?

Yes: Continue investigating the idea.

No: Drop it and move on with your life.

Quick and simple.

Caution.

Like any tool in your toolbox overuse the mission statement and your co-workers will become numb to its effects.  Engineers smell b.s. from a mile away, if you show up Monday morning chanting your company’s mission statement, wearing a shirt with the statement on it, and hand out pictures of you posing with the mission statement you will lose them.   “Sure boss, great idea, I’ll put on my hat with the mission statement tomorrow…today it would clash with my outfit.”

If you are going to take the time to do so, write the mission statement with care, capture that goal, write it in such a way as to inspire people to work towards that goal, but be sure to not over use it.