Code Usability
If you regularly hear or use the term Usability in your work, you are probably a UI developer or a front-end Web developer. In general, the issue of usability becomes a concern the closer you get to your front-end user.
You’d be surprised to learn that the issue of usability is (or at least should be) a concern no matter which part of the system you are writing. It doesn’t matter if you are responsible for an infrastructure framework, a piece of business logic, or an in-house general purpose library. Usability must be an important consideration when designing and writing the component you produce.
You might be wondering, what do I mean by usability of back-end components? After all, the user (your customer) has no direct interaction with them. Most chances are that he isn’t even aware of their existence. That’s all true. But we, as developers, offten tend to ignore another group of users: ourselves.
We, as a group, are users of the code we write. Almost any piece of code you write will be used and supported for at least a couple of years either by you, or by your colleagues. Some products live for over a decade. This means there will be many future developers who will use the code you design and write today.
This makes usability an important consideration for any component in the product you write. Even the most hidden component in the system still has direct interaction with some users: the developers who use it and the developers who support it. Shouldn’t we consider usability from their perspective? If the code you design and write today is difficult to use, any development task involving it will take longer and will be more error-prone. Aren’t these issues important enough to consider usability as part of the development of such components?
So, what is usability of a software component? Let’s start with the the component user’s perspective. The user of a component must feel confident when using it. The interface of a component must be clear and coherent; it should be as self-explanatory as possible; and it should be simple. This applies both to programmable interfaces and network interfaces. I often see component’s interfaces which are not trivial to use: it is not clear when each method/request should be called and what is the result of calling it; it is not clear who is the owner of objects passed to and from methods; methods/requests have some undocumented side effects which can severely affect their caller; etc. These are all usability problems: they make the component hard to use.
The same applies to the developer who will have to support the component: if the code is not simple and clear, and the design is not coherent, any maintenance task becomes a nightmare.
The keyword in this discussion is confidence. Any developer working with a component, either externally or internally, must have confidence in it. She must know what to expect of it when calling it, or when changing something within it. This is the "user experience" a developer should expect, and nothing less. This will help her do her job better, and with fewer mistakes. In turn, this will contribute to the usability of the code she writes.
The usability of software components has the greatest effect when we talk about reusable components used in many project (see my article: Testing a Framework for more on this issue). However, when you think of it, every component and every class within it should be designed and written to be usable. The fact that a component is used only in one product is not that relevant: it still might have many developers using it either now or in the future.
March 8th, 2006 at 1:01 pm
[…] Related Article: Code Usability […]