subscribe: Daily Newsletter
search the site
Application development: to reuse, or not to reuse
While some in the field of software development are ardently advocating the advantages of reusable code and software components, others are taking the more balanced view that reusability should be applied only when it is likely that there will be a case for it.
One proponent of the latter approach is Nick McKenzie, technical director of enterprise software development house nVisionIT. For one thing, says McKenzie, the concept of reusable components is not a new one.
“While the focus on service oriented architecture may have reusability under the spotlight, the reality is that developers are facing the same challenges as before. Someone didn’t suddenly wake up last week and decide that reusing code is a good idea.”
McKenzie explains that object oriented (OO) programming was once all the rage for the very reason that it promised reusability, with the object as a component for reuse.
“However, the promises were not quite met. Was that a failure of OO programming? No. The failure resulted through the fact that despite reusability, the component may not be ideal for the next project.”
Furthermore, McKenzie says making a piece of software or code flexible and reusable takes additional time. It also adds complexity.
“Think of it as designing a Rolls Royce when a bicycle is required. Sure, it might perform better and offer the capability to be reused in other projects, but spending too much time and effort on the design can quite simply make that piece of software financially unviable if it is never reused.
“Companies need to evaluate each element of the design and pick your battles in terms or reusability. Identify one area that you are going to get the benefit from and get that right, rather than going for reusability as a cross-cutting design goal,” he says.
There is also the issue of shoehorning an application around existing components.
“Reusability has to be approached with some caution. Programmers may fall into the trap of believing that short cuts can be taken by drawing on code from preceding projects. That can also raise issues of ownership where the software is being provided to third parties,” he says.
While McKenzie is loath to advocate SOA as a panacea, he does believe it offers a better interpretation of reusability.
“This is where there is a definite advantage to services orientation. It requires an understanding of the context in which the service will be used, describing what the service has to do rather than how it has to do it. OO tends to be very specific to each implementation, with the objects too finely grained,” he says.
A point that he makes is that there will be no getting away from requiring good programmers capable of understanding what the business needs.
“Reusability should never be considered in terms of reducing development overheads. It has its place, but too much attention to creating reusability may have the opposite effect of having to include so many different requirements that it actually limits the suitability for the immediate application. In effect, components can become so generic that they have no value.”
And, says McKenzie, if developers spend additional time focused on making software components reusable, but the code is never reused, that time has been wasted making software which is also more complex and hence more difficult to use.