I’m seeing how important step 12 from the joel test is in software design. The most important part of any software product is usability. Usability is defined as:
The effectiveness, efficiency, and satisfaction
with which users can achieve tasks in a particular environment
of a product. High usability means a system is: easy to learn
and remember; efficient, visually pleasing and fun to use; and
quick to recover from errors.
If your product is not easy to use then it offers no real value to the user. Why? Because the user is trying to achieve a task with your software. The user chose your software as an effective, efficient, statisying means of accomplishing that task. That is where the value of the software lies. Forcing the user to learn your software or learn your way of thinking when they interact with your software is taking the main reason your software was choosen and tossing it aside. In other words you’re removing the only real valueable reason they sat in front of the interface to your product and replacing it selfishly with an introduction to how you think and work. Analogy: Suppose you asked me for a ride home from a party. Let’s say I agree to help but then I stopped by the ATM and ask you to pull out some money for gas. (Nothing wrong with that, right?) Imagine that I then forced you to take out an excessive amount (much more than $20) and used that money during our trip. Our trip includes several toll booths and turnpike fees. (Getting crazy but only if those tolls were along the way home right?) It involves a stop by a Burger King because I’m hungry and a pit stop by the club where I use your money for admission. We go around many different places and have an adventure. (Think Harold and Kumar.) Our trip finally ends in the parking spot in front of your home. Have I done you a service?
Unfortunately many software products behave in just the same way, they take the user for a ride to places they never intended to go. The big problem being the software forces the user to sacrifice his/her main mission soley because the developer had inadequately understood or cared for that mission. That’s the problem that results when you don’t prioritize testing. More accurately stated, that is the problem when you don’t prioritize the use requirements of the software. Starting on an implementation without a test harness is like starting down the road when I haven’t even asked where you live. “Yeah, we’ll get you home!”, goes the thought process but along the way lets have fun. It’s really fun to develop and really easy to get distracted even when you have solid clear requirements. It is possible to fill requirements accurately in absence of a test harness but you are far less likely to do so and far more likely to develop extra extraneous code. This article is not about the merits of Test Driven Development, though I had to sneak the idea in.
Why am I saying all of this? Bear with me, I’ll explain shortly. Right now lets talk about usable software. We should agree that it’s the most important thing. If your programming artifacts are not usable then you have a real challenge creating a usable product. Let’s think about that more closely. If you need to write code to use your product then your product offers no value. Zero value is realized. Nothing. It doesn’t matter how fancy the product is there’s nothing practical about writing software to use software. I exaggerate somewhat on that point but it is important to think that way when developing. The fact is that is is possible, always possible to create a product that requires no programming to use. (By the way, for the purpose of my argument let’s consider configuring through config files or command line options/switches programming because it is a means of encoding, or coding, your wishes in a dialect that is not english grammar.) More important is the fact that it is not any more difficult to create a product that requires no programming than it is to develop one that does require programming. In most cases I dare say it is easier to create a product that requires no programming to use. So why does there always seem to be a programming dialect, config file, or command line argument for most software? Going back to what I said earlier about prioritizing the requirements you will understand that the primary requirement for every piece of software is that it be easy to use. Better stated, the primary requirement is that the software be focused on getting the user’s task accomplished. That primary requirement is the first one to get dropped in favor of covering all of the potential situations it will be used. So a developer will typically prioritize the re-use of his/her soon-to-be-developed product over the initial use. Surely the product will be used in more than one way, even by the same users, right? So why not make sure a vast majority of the product does not need to be re-implemented?
The problem here is that when a developer does not focus on each requirement individually neither does the resulting product. Then you have some developers on the more extreme end that focus on all the possible end results of using their product before the thing even gets started. (They pose questions like, “What about performance and data volume? Will it clog the network? Can it talk through firewalls?”) That’s another topic for another discussion. Every developer loses focus from the primary requirement as soon as they begin development. So then the result is a bunch of code that either requires configuration, additional programming, or command line switches to operate, hard to use code.
Grab the next person in the hallway (or in the next cubicle) and ask them to use the product you’re currently working on. That highlights the primary requirement of your product. The first thing that person wants to do is use it. They want to accomplish the task that your product is supposed to assist them with. If they can perform that task without you telling them about your product then you’ve done a perfect job. If not then you have some polishing up to do on not only the interface but your approach to development. The day when we can have Hallway-usability-test-driven-development will be the day when all of the programming for programs starts to disappear. My point is the ignorant user (the person from the hallway) should be the primary driver of your development process. (At least have the guy in mind when you write the first lines of test or production code.)
Am I being overly critical of command line options? Perhaps but not by much. I believe that the simpler an interface is the more valueable it is, even and especially at the requction of features. It would be better to offer several commands for different tasks than it would be to offer a single command with switches.