Why are contract outsourcing and offshore development failing to deliver the expected benefit of lower costs and increased end-user satisfaction to enterprise software development users? It seems that lower rates per hour and better management of human resources are not enough to overcome the problems associated with the central issue of lack of engineering discipline. In most other industries, real cost savings matched with increased productivity that translate into fundamentally lower production costs have been the result of process and manufacturing reengineering, not simply of lowering labor input costs. The cost of building a car has actually declined in real dollars over the last 20 years, even as average hourly pay has increased. By and large, this has not been the case in software. Without looking at the way software is developed with an eye toward reducing the amount of labor input - and instead simply trying to lower input costs - companies have not been able to meaningfully affect the overall cost of software development.

It is not that these engineering disciplines do not exist; it is simply that they have not been put into practice. Much of this can be blamed on the fact that software is fundamentally different from other products. It takes no physical plant to build software and requires no meaningful use of raw materials other than labor. Because of these two facts, it has always been much easier to "dive in" (build first, design later) and just build or fix software than it has been to take an engineering approach - which in other industries must be taken before anyone will sign off on building a plant or expending resources that have to be purchased. Even so, much of the problem can be laid at the feet of computer science itself. While much is made of new languages, compilers, and editors, very little attention is focused on that process and tools that can make a significant dent in development costs.

The idea of using prebuilt pieces of software (components) as building blocks is not new, yet very little has been accomplished in companies actually using them. Most companies, while speaking some of the language of reuse - the hallmark of component development - have no defined structure, metrics, or management for real reuse initiatives. This is surprising given that we estimate that a company could lower their overall development costs by as much as 50% through formal reuse initiatives.

Reusable components are not limited to a class, library, or object but rather are an entire package of assets. Components can be open source, commercial, off-the-shelf, or homegrown assets. No matter where they are accessed, it is important that they are constructed in a consistent and uniform manner. Best practices state that every component must contain the same consistent deliverables. A developer will waste more time determining how to use the component if each component has a different style and set of deliverables. The more time the developer has to spend learning the component, the less valuable the component becomes. Below is a list of important deliverables a component contains.

Documentation:

• Component Specification - The component specification describes the design patterns, algorithms, and makeup of the component.
• Use Case Diagrams - Graphically depict the usage of the component from an end-user perspective.
• Class Diagrams - These diagrams give an overview of the classes in the component and illustrate the relationships among them.
• Sequence Diagrams - Sequence diagrams are used to display the order of operations and interaction between classes. These diagrams are organized by time and message flows.
• XML Documentation - Provides developer-level API documentation.
  Test Suite (Built using a framework such as NUnit):

• Unit Test Cases - Unit test cases are used to verify a specific unit of work and check that the expected result is returned independently from the rest of the system.
• Accuracy Test Cases - The test cases are written against the public API to verify the correct results are returned.
• Failure Test Cases - Invalid data is run against the classes to verify that the appropriate errors and exceptions are returned.
• Stress Test Cases - Large datasets, multiple threads, and other load-stressing techniques are used to simulate load on the component.

Source:

• Commented Source Code
• Commented Test Suite Source Code

Build Environment:

• Build scripts for compiling, testing, and deploying written in products such as NAnt or Visual Studio
• Common directory structure for component source, libraries, documentation, test suite reports, and configuration files
• Support for multiple build environments (i.e., specific .NET Framework versions)

In order to properly build components, industry figures generally agree that the cost is in excess of 50 percent extra to build a component for reuse rather than building it directly into an application. This cost exists due to the extra effort it takes to examine the functional requirements that are outside the scope of the application. The interfaces must not only meet the application's desired functionality, but should also be extensible for other uses.

Once the component has been designed and built for reuse, the next time the functionality is needed by an application the timelines and cost of building the application shrink dramatically. For example, at TopCoder we will use any component that matches 80 percent of the required functionality. To fulfill the last 20 percent of the functionality we can either embed the logic in the application code or, more ideally, extend/wrap the component to support the remaining requirements. The effort to modify a component is significantly less than building the logic from scratch. In order to look at this mathematically, the equation would be:

(n * IT) + RBE < n * BE.

• Figure 5