Software professionals spend a lot of time creating, reading and maintaining code. Because so much time is spent using code, it can be a good idea to invest in the design of the code itself, in terms of usability.
Take a look at most TVs these days, TV manufacturers seem to be pouring tons of money into making buttons blend into the TV without realizing that people then can’t find the buttons and they’re a nightmare to use, even if you do find them. Here are some buttons on a TV, this is the bottom of an LED TV:
Yes, there are actually buttons there, about 5 or 6, here’s a zoomed in view of the buttons:
Here, I added some red to indicate where the buttons are at, look at this and then look back above and you should see them now (hopefully this visual priming helped):
This is the epitome of horrible design.
The same thing happens in code, for far too many reasons, people tend to write code that’s just as obscure as those buttons:
Credit to http://imgur.com/TBznfsY for this code sample
Now, not all code matters enough to warrant obsessing over its usability. But when code is important, why not attempt to make it more usable? And by usable I mean comprehensible, maintainable and whatever else you routinely need to work with the code effectively.
Here’s a simple process to find some of the significant problems and work on improving them:
- Identify code that’s part of a system that actually matters. Code that provides significant value to the business. Not code that some programmer feels is really important. Something that produces value. Why does it need to matter? Because who has the time to fix any random piece of code? If you have the time, wouldn’t you want to fix the most important code first? And then if you have copious spare time beyond that you can consider prioritizing fixing code that doesn’t matter as much.
- Identify routine tasks in terms of usability of the code. Frame these in terms of the tasks that are frequently performed on the aforementioned code. These are things you routinely do or ask about the code. Here are a few ideas:
- How does the code handle situation X.
- The code should do Y in situation Z. Are there any discrepancies in how the code is actually implemented?
- Where should we add additional testing of this code?
- This code currently supports A, B and C. Modify it to support D.
- Then, identify 2 or 3 individuals with the requisite background to perform the above tasks, but pick people that have never worked on the system before. They’ve never seen the code. They’ve never used the system. They have no idea how things should work. They have no background nor biases. Pick them like a jury would be selected for a murder trial. You want objective, unbiased individuals.
- Don’t get too caught up on credentials, the level of expertise is irrelevant in finding big problems with the design of code.
- Take the above tasks, and determine a reasonable subset of them to accomplish in one to two hours.
- Plan a day to run code usability sessions with the 2 or 3 individuals.
- Schedule a time for each individual.
- Invite everyone possible to observe the testing. Just keep in mind they will be isolated from the testing so as not to bias it. Anyone that helps with planning, development, testing, releasing, supporting, managing, etc. The people who have a stake in the code being usable.
- Find someone to facilitate the code usability session. This person has to be capable of remaining objective, in other words, be able to hold a poker face regardless of what is said during testing.
- Run the code usability testing sessions, each session should roughly go as follows:
- Bring the individual into a testing room
- Give them some initial instructions:
- Explain the purpose of the testing
- Tell them they aren’t being tested, the code is being tested
- Tell them you need candid reactions. Be frank. No feelings will be hurt. This is about improving.
- You may want to record the session, especially if the facilitator would like to later review and capture their own observations since they will be focused on running the testing objectively.
- Go through each task, or as many as you can get through in the allotted time and ask the individual to perform the desired task. Do not provide any guidance whatsoever. The facilitator simply needs to keep the individual talking throughout to explain what they are thinking, seeing, doing etc. You want the participant to verbalize as much as possible. Be careful, even how you nod your head or say OK can give leading hints. Let them answer their own questions.
- Gather observations about serious design issues with the code.
- At the end, thank the individual, and consider some form of compensation.
- As soon as possible, sit down with everyone that observed the session and decide on what the biggest problems were. Actual problems the participants had, not what people have had a burning desire to change about the code. Prioritize the biggest problems and then go about fixing them.
This list is by no means comprehensive. I’ve formed it along the lines of Steve Krug’s template for web site usability in his took Rocket Surgery Made Easy.
You might be surprised with the quality of improvements you can identify and make, and how much you can improve the usability of the code itself.