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?