Value of Code Part II – Reusing Code

Thanks for the great response to part I of 'Value of Code'. The next two articles delve into further detail how Good Code Reuse can resolve the problems of Code Depreciation. There are two parts in the Code Reuse equation. This article deals with issues with reusing code. Part III (still being written) deals with how to write reusable code.

Introduction

Now that we have established that the value of code decreases over time, let's see how we leverage that knowledge. The best way to tackle this problem is to avoid writing new code but reusing code that is designed to be reused. Before reusing code, you need to solve multiple problems.

Reusing Code

Buying or reusing code is always preferable to writing your own. In most cases, given the cost of good code development, it is impractical to write code for everything a product requires.

Barriers to Code Reuse

These are the general barriers to code reuse:

1. Under Estimating Development Costs.
2. Not Invented Here mindset.
3. Insecurity about not adding value.
4. Issues on Component Evaluation process, Quality, or Documentation.

A. Under Estimating Development Costs

Most developers, when asked how much time it will take to write a particular component, come up with guess estimates that are much lower than the final costs.

For example, let’s say that you want to write a good status bar component for Windows forms. What is the cost? Most developers would estimate this as couple of days of coding. But the cost of the component is not just coding. It also covers requirement analysis, design (internal code + external interfaces), actual coding, unit test coverage, bug fixing, interface documentation, and long-term maintenance. And these are just developer tasks, other folks are involved in the development process also. This component will consume QA, documentation, product management, and engineering management resources. So much, for the two days coding estimate.

This most common mistake that most teams make is to calculate the coding costs only. Understanding how to calculate the true cost of the code will go a long way into helping you make better decisions.

B. and C. Not Invented Here mindset and Insecurity

These are two related issues. Most developers think their job is to write code, and the amount of code they write forms the basis for their evaluation. Developers need to be told that they exist to solve problems innovatively. Solving a problem with less code is better than solving the same problem months later with more untested code. NIH needs to be handled as a part of the company culture. Most managers praise the coder who spend three nights in a row and write a few thousand lines of code to implement the feature, but will hardly acknowledge a developer who implement a feature by buying or reusing a component. After all, the perception is that the component developer did the hard work.

If you have a company culture that rewards more coding work, you will always have a NIH problem. If your interviews test potential developers on low level coding tasks (like, how to reverse a linked list) but not on how to write or use reusable code, you are hiring good coders.

For reuse to work, you need to have a culture that focuses on rewarding reuse, and hiring developers who know the value of reuse. You cannot have a culture that makes developers insecure about not adding value because they use someone else’s code.

If your reuse programs are failing, take a good look at your culture. The main reasons for reuse failure are found in the development culture rather than any technology reasons.

D. Issues on Component Evaluation process, Quality, or Documentation

Quality is a serious and the real issue with most reusable components, and unfortunately, there is no magic portal that documents the quality levels of various issues. (Hey, that is a great idea, but let’s not digress.) The only way is to follow a disciplined and strict process to help you evaluate components and address the quality and documentation issues.

How to choose the right reusable component

This may seem like an art rather than a science but it does not have to be so. In the above example, the choice would be not spending time in development of a status bar component. There are dozens of status bar components available in the marketplace but you need to spend time in Evaluation, QA, and integration of those components.

Before you choose the partner, choose the type of company you would like to have as a partner. You want to make sure that the company has:

• A good track record.
• Good Support polices.
• A reputation for high quality code.
• Access to source code (at least via an Escrow).

Next comes the actual component evaluation part. Don’t make the mistake of assigning this to a junior developer. You want to make sure that choosing a partner to work with is serious choice and needs to be handled by a senior developer. Doing background research to find out what others are saying about the component always helps. Talking to the support folks at the component vendors lets you understand the technical expertise of their support staff. Playing with their samples and looking at their interface design is something that will tell you how much thought went into the component design process.

Once you narrow down your list, get someone from your QA team to run some automated tests on it. Treat the component as an untested resource. If the component has an effect on the deployment strategy, measure it and make sure that it is acceptable.

When integrating a third party component, make sure you use an abstraction layer to insulate you from any changes. If you decide to use a new status bar tomorrow, then the only changes you should make is changing the MyStatusBar class. An Abstraction layer protects you from changes that happen in technology, business requirements, and from other bad things (like the component has a resource leak).

Advanced Reuse Concepts

Reusing code does not mean only reusing a component. It could mean reusing a framework or an application. For example, if you are writing a web based application that interfaces to some hardware device, you have three main choices:

1. You could write a CGI application that does all the work.
2. Use a PHP library to take care of templates, authentication, etc., and concentrate on domain logic and using all the library features.
3. Integrate your domain logic as a module in a web portal like DotNetNuke, etc.

Choice 3 has best reuse capability, but there are some product management issues that you may need to sort out first. Choice 1 is a bad choice, you should be concentrating on your business logic and domain strengths. Choice 2 is a reasonable choice but there is some work involved to use the library features to implement templates, authentication, etc.

Implementing your solution as module that requires DotNetNuke, MS Office, Sharepoint, or a J2EE application server does add an extra requirement for your application, but in most cases, it may be worth it. It does not make sense to solve a problem that someone else has solved before. Reinventing the wheel does not pay as much as it did during the DotCom days.

Conclusion

The only way you can avoid code depreciation is through reuse but you need to be disciplined and follow a strict process. Reuse enables you to do more with less.