Reuse your softwareReuse your software

It sounds crazy, but in the world of software development, programmers create code no one else can use, so many projects must start from scratch. Although the idea of re-using software has existed since the days of 1's and 0's, few programmers actually produce such code.

In most large companies, engineers in design labs produce software to verify their designs work properly. When a design becomes a product, the test engineers on the manufacturing line also need software to test products before they go to customers. If the company can quickly adapt the lab's verification software to also run production-line tests, it saves money and development time. That's the beauty of software reuse.

When a company relies on a contract manufacturer (CM), the benefits of using reusable software become more apparent. If a CM must independently develop test hardware and software, this effort may delay a product's introduction. But if the design company supplies a test system and much of the same software it used in its labs, the CM incurs few costs and gets into production quickly.

Transferring reusable test software to a CM has less obvious benefits, too. First, the design company knows the CM will run the same tests used during product development and verification. If the CM had to write test software, there's no guarantee it would test a product exactly the way the design engineers intended. Reuse of test software ensures the same test criteria apply in the lab and on the manufacturing line. Second, by moving reusable test software from the development lab to the production line, the final production tests take advantage of the same types of measurements-embodied in the software-used by the design engineers who developed the product.

Most software reuse efforts occur at companies that can apply a software reuse philosophy to ensure the smooth transfer of design-verification software into manufacturing-test applications. This approach lets one group develop test software that many groups can apply to their own needs, without having to start individual development efforts. People who control budgets must understand, though, that reusing code in future applications usually requires additional time and money now. It takes more time to thoroughly understand test requirements and write solid, reusable code than to quickly patch together software that solves an immediate problem. Code reuse requires a long-term view of investments-invest now and hope for a payoff later on.

Tool Up

After a company commits to pursuing software reuse, its developers must choose good software-development tools. In addition to looking at test software such as LabVIEW, ATEasy, and TestPoint, developers also should consider programming languages in Microsoft's Visual Studio .NET package. This suite of tools includes Visual Basic, Visual C++, and Visual C#. Because Microsoft has adopted a Common Language Specification (CLS), programs written for a compliant language, such as Visual Basic, can easily interact with software components developed in another compliant language, such as Visual C++.

The CLS defines, for example, cross-language data types, variable-naming conventions, keyword uses, and so on. Thus a group can develop reusable code in one language and another group can drop that code into a program written with a different language. In the past, most reusable code could exist only in one language.

Software developers also must investigate commercial software "modules" that create test reports, chart statistical process-control (SPC) information, manage network communications, and so on. This commercial software represents the optimum in reusable packages-someone else guarantees the software will work, supports it, and keeps it up to date. Don't create what you can buy.

Before programmers jump into a project and start to write code, they must look at an entire problem and think about how they can apply reusable code to it. They need to ask, "What information do we want to give the software, and what do we want the software to tell us in return?" And if they really want others to use their creations, they also should ask, "What will make people want to reuse this software?" Following several guidelines can help produce reusable code:

Software developers shouldn't aim to impress others with their programming skills. Adding the proverbial "bells and whistles" may seem cool, until someone hits a snag caused by one of these extra "features." Remember, "customers" will review reusable code, so make it easy for them to understand it and use it in their applications.

"Understandable" code results from thinking about a user's needs. If, for example, a user needs to sense the state of eight switches an input port, a C-language statement for this task might look like:

Motor_Switch_Data = ReadSwitchPort(Switch_Port_Number);

Rather than hard coding the I/O port address in the code-"We know motor data always comes from port 123"-the developer defined the I/O port address elsewhere in one known place. Doing so makes it easy to change the I/O port assignment once, rather than track down every hard-coded statement.

It's less obvious why developers shouldn't hard code constants such as pi, the speed of light, the number of grams per pound, and so on. No one should need to change these quantities, but defining them once and then identifying them by name, say, Grams_Per_Pound, makes it easier to review and understand the code.

Now, a programmer must test the I/O statement above to ensure it returns the eight bits from a given set of switches. If programmers expect others to use their code, they must ensure their code won't "break." Programmers can't predict how their customers will try to use reusable code, so they must prepare for the worst.

If a piece of software cannot operate on negative numbers, for example, developers must ensure that their code will trap any negative inputs and report an error condition. Documentation should define what conditions will cause errors, and should indicate the message codes that an error condition will produce. If reusable software will display error messages-and it should-they must display useful information. Simply displaying an error message such as "Fatal Halt" has no value. Users need to know what caused the error and where it occurred.

Programmers must document what they do to ensure others know how to apply reusable code. Even though the code, such as the simple example above, seems self-explanatory, documentation helps users understand how the switch data comes into the computer and any limits on the Switch_Port_Number they can use. Also, documentation should explain any dependencies and the use of libraries or other code.

Jack Ganssle, a pioneer in the applications of microprocessors says, "A module isn't really re-usable 'till it's been reused three times." That means a piece of reusable software will go through several iterations before it becomes truly reusable. Invariably, users discover problems with the code or it doesn't operate as flexibly as it could. Ganssle figures after three programmers have applied reusable code, it's ready for general distribution. Developers must listen to customers who have complaints or ideas for improvements.

Programmers involved with reusable code also must think about how to make their code available to others. In some companies, word of mouth suffices to spread information about software developments. Other companies may rely on an Intranet or on project-management software to keep up with reusable-code projects. People involved with open-source projects frequently use the SourceForge.net website to track projects and make code available to others. SourceForge also sells an enterprise version of its software, and other vendors supply source-code control software that simplifies the task of managing and tracking large software projects.