UX Test Your Code

So you think that new module of code that you just whipped up is just fine? You even wrote it with a pair or two! All of the names are the best that you could think of, the thesaurus is still smoking as it sits next to your keyboard. Control flow effortlessly flows from one expression to the next. Data dances in happiness for the structures that you have decided to use. This is not in any way going to be a maintenance problem!

Are you sure? Have you tested it? No, not that kind of testing. I trust that you have a good set of unit tests. Maybe even some nice acceptance tests that were looked at, or provided, by your stakeholder. No, what I mean is have you tested that it won’t be a maintenance problem?

Sure, sure. It was written with pair programming. You swapped pairs several times a day. You probably even stepped away from the keyboard for a bit, went to a whiteboard and hashed out what you were going to build. You communicated this to the team and you all knuckled down and gave it your darnedest. But did you check that someone else can understand it?

What? Someone else? What do I think all of this pairing is about! All of this whiteboard writing. All of these acceptance test shenanigans!

Bad code is not employment insurance

The problem is that your entire team might have succumbed to groupthink. Every one of you got on the same page and stayed there. You might have become blind to something that you think is obvious, but is completely unintelligible to someone outside the group. So let’s do a little test and show that code to someone who has not seen it before. Let them be the judge of how good it is.

Now I’m not saying that you should be doing a sit down formal code review. Think of it as a simple form of usability testing. Grab another programmer that is familiar with the domain and sit her down in front of the code. Ask her to perform some actions on the code and to answer some questions about it. You might try:

  • How does this code achieve foo?
  • You need to add functionality bar. Show me what will need to change.
  • When I perform action baz in the application why does it respond with blub?

Watch how your subject interacts with the code. Watch her fumble and second guess her understanding. See the ease with which she performs some actions and has trouble on others. Now take that information and try to improve your code!

Something that you really need to remember when doing something like this: you are not testing your colleague! Any failings that the test uncovers are not because she is “stupid” or “doesn’t understand,” they are because the code you wrote wasn’t fully up to the task at hand. Having that pointed out can be hard to deal with, but it is there in the data. Now it is up to you to improve and figure out how to fix the problems. Good luck!

3 thoughts on “UX Test Your Code”

  1. Interesting idea. Have you used it in practice? How detailed do you make it? Or to rephase: how long does one such review session take?

    I like the “how does it achieve/why it responds with questions”, but the third one seems to be a bit of an outlier to me – wouldn’t you be asking obvious, leading questions, looking for extensibility points that the current design accommodates? Real change request usually come unexpected… Or is that actually irrelevant from the code UX perspective?

    1. The team I’m on at TIM Group (formerly youDevise) has used it once so far. I wanted us to make sure that a big rewrite we had just done had fulfilled the goal of being much easier to understand. We came up with the idea of trying doing something like usability testing on the code with another developer on the product who had not worked on the rewrite.

      Yeah the question about how to add functionality is a bit leading. I don’t think we actually used that kind of question either, but I think it has some merit. Can someone translate from what is being asked to be changed to where that is handled in the code. Maybe they can find it quickly and the code already has a lot of clear affordances. Maybe they search for a while and get completely lost. Maybe they quickly discover that you are asking them to do something that the code does not readily allow. I think when asking about adding or changing functionality you aren’t looking for whether the code can do it or not, but how well the programmer can interact with the code to discover the modifications that need to be made.

  2. Nice idea!

    We write tests to verify that important functionality works; maintainability is a key business-goal of most software; so why not test for it. How else can you verify that the maintainability goal has been met. Now if only there was a way to automate it…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s