Intelligent Enterprise

Better Insight for Business Decisions

RSS
Webcasts
Whitepapers
Subscribe
Home

October 24, 2001

Don't Make Me Repeat Myself

What effect will code reusability have on strategic business applications?

By Michael J. Hudson

Developers have an old adage: Those who write code are condemned to repeat it - over and over and over again. I can't tell you how many times I've set up a role-based security scheme or written a messaging system from scratch. Each successive implementation may have had small differences, but on the whole, the ideas and the framework of the original design were the same. So, why not write it once, store it somewhere, and bring it back when you need it?

That idea, my dear reader, is called "reusability" - a holy grail for the development industry for years. Although the recent economic downturn has made achieving this goal even more important, it takes a lot of internal and external collaboration to get it working.

WHAT IS REUSABILITY?

In the context of the development community, reusability is simply the ability of software artifacts (specifications, designs, or source code) to be used again, in whole or in part, for new applications. Software reuse doesn't just mean recycling the code itself into a new piece of software. In general, it can include any asset, such as specifications, design models, and user documentation, deemed necessary for implementing or updating an application. And in most cases, you need all these ancillary artifacts, as well as the code itself, if you want to recreate anything useful. On top of that, reuse may occur within an individual software system, across similar systems, or in widely different systems. It can even occur across multiple enterprises, not just within your own.

Reusability has recently become more prominent in the computer industry for several reasons. As the economy slows down, IT budgets have also started to dwindle. More and more managers are trying to balance the need to add more complex functionality, consistent dependability, and improved quality to their systems, while also cutting costs and increasing productivity. The integration of reuse into a development process translates into being able to do both. Reuse also helps you rapidly prototype components, which increases system interoperability.

TAKING THE LONG VIEW

These reusability aspects sound very promising, so why hasn't this idea caught on more before now? As I mentioned, software reusability can be very complex, especially when you're trying to accurately define or find reusable components. Planning and designing for reusable components takes a lot of concerted effort. Because you can only quantify the long-term benefits of reusability (decreased costs for software development and maintenance), convincing others in the short term to expend the time and resources to do this is difficult. And even if that is done, advertising or finding what kind of reusable components already exist so that they can be used again takes even more effort.

So, the real question is whether true reusability is even feasible. In the nonsoftware world, reusability is seen almost everywhere in the design of many products and it's essential in the ability and ease of completely replacing a specific part. For instance, almost every part of an automobile is made of replaceable, reusable parts. I can take the battery out of one Chevy Camaro and put it in another similar Camaro. Shouldn't the software world be this easy? Although this analogy holds true for software in many ways, realistically, software reusability is more akin to replacing the brake pads in a Ford Taurus with the brake pads from a Volkswagen Beetle and still having it work.

In any case, Rome wasn't built in a day, and the answers to all these software reusability problems won't be solved overnight. With the challenges of time-to-market, legacy software, maintainability of systems, and general technology overload, often the last thing on CTOs' minds is their systems' reusability.

RESCUING REUSABILITY

With all of this said, however, a significant movement is underway in the industry to improve practices and technologies to benefit from reuse without extravagant investments in time and money.

One of the new entries into the world of reusability is the currently ongoing development of a specification for describing reusable software assets called the Reusable Asset Specification (RAS). It is an open standard that Rational Software Corp. is initiating. Simply put, RAS provides a number of guidelines for how to describe, develop, and apply your library of reusable software assets. It uses the unified modeling language (UML) for design models and Rational Unified Process (RUP) for workflow descriptions. Its goal is to be an industry standard that not only will let third-party tools ease the creation of reusable components but also facilitate collaborative development environments among organizations. One of the downfalls of past attempts at reuse has been the focus on just code. RAS attempts to finally combine the implementation code with the equally necessary design artifacts and user documentation.

Efforts are also underway to create component-mining software that will help recover existing software artifacts. Salvaging these artifacts reduces much of the initial work of planning and designing for reuse. The software itself does the hard work of going through all of your existing software infrastructure and plucking out the pieces best suited for reusability. When companies begin developing a new system or application, the first thing software architects do is use this mining software to look for artifacts that are similar to their current needs. This step greatly reduces the time and effort to both define and find all the existing assets within a company's enterprise.