Arbitrary reuse of code components could deteriorate overall usability. In this column, Linda Hayes explains the good and bad qualities of reusability and five factors one should keep in mind when managing reusability to get the most of it.
Reusability is one of those attributes we assume is good. After all, reusability implies less work. Isn't it easier to use something that already exists than it is to create something new? Not necessarily. Sometimes, reusability creates more problems than it solves. The trick is to know where to draw the line
The Bright Side
An axiom of software and test automation development is that less code means less development and maintenance. This leads to strategies for reusing code whenever possible, usually by organizing code into components that perform discrete tasks that can be shared in multiple places. Done right, this can save coding time and effort.
You may even buy reusable code components. Software libraries provide generic functionality for common tasks such as spell check, sending emails, or designing reports. You can also acquire custom controls to add power and pizzazz to your user interface with minimal effort.
Reusable components are also employed in keyword test automation frameworks to shield less-technical users from the complexities of coding. In this scenario, skilled scripters develop a component library that can then be assembled into test cases by domain experts. As with software components, you could acquire libraries from others and shortcut implementation time.
Clearly, reusability has benefits, but there are some drawbacks.
The Dark Side
Without proper design and control, reusability can reduce code readability, maintainability, and usability. Code readability is compromised when the reusable segments make it difficult to understand the logical flow of the code without actually tracing the execution. Depending on the level of component granularity, debugging code comprising components may actually take longer than linear code.
This, in turn, may cripple maintainability, as future changes could take longer or introduce unexpected effects because the coder has an incomplete understanding of the potential impact of modifications. Extensive use of reusable components requires the developer to understand the function of each component. This isn't always the case, especially for someone new, and may make the learning curve steeper. And changes to a widely used component can, naturally, have far-reaching and sometimes unintended results.
In test automation, complex application behavior may result in too many components, thus confusing users and reducing usability. In one project, a company that developed hospital management software decided to employ a keyword framework so their business analysts, who understood the ins and outs of the functionality but had no coding skills, could develop automated tests.
It started out well enough, but as users encountered variations in behavior, they had to request additional components. For example, the admissions process varied based on whether the patient requested a semi-private or private room, whether a private room was covered by insurance, and if the type of room requested was available. Each of these variants caused a change in the application behavior and thus required another component.
After about six months, the number of components swelled to over seven hundred, overwhelming the developers and confusing users. Selecting the right component and fitting them together became, as one user described, like a "giant jigsaw puzzle" where the pieces were so small it was hard to see where they fit into the overall picture. In the end the framework was abandoned. So, where do you draw the line between reusability and usability?Drawing the Lines
Managing reusability to gain the greatest benefit and avoid pitfalls depends on five factors:
- Overall Design. Unless you start with the big picture, designing the pieces will be an ad hoc process and, therefore, endless. Begin with a well-thought-out architecture so you know which components can and should be reused, where they fit, and their precise function.
- Balance Granularity. Resist the urge to make too many components. The greater the number of components, the harder it becomes to manage and maintain them. Some duplication of lines of code may be preferable to managing yet another component. Less may be best.
- Enforce Standards. You can't use a component if you don't know it exists, where to find it, or what it does. This means that naming, documentation, and design conventions are a must. Mystery components will clutter your library and cause duplication and confusion.
- Centralize Control. As with any software, changes to components must be tightly managed, including version and change control. Don't let just anyone modify a component to suit her needs, as this may cause unforeseen problems.
- Provide Training. Make sure everyone on the team is trained on the component library, including where it can be found, the names of the components, the functions of each component, and the conventions and procedures for managing them.
Done right, reusability and usability enable each other. Approached casually, they work against each other. So don't just assume reusability is right: Make sure it is.
