The Code Reuse Myth

I am of the firm belief that code reuse is a personal responsibility, and should never be a corporate endeavor. Unfortunately, thousands of CIOs and project managers disagree. There is a pervasive attitude among out-of-touch higher-ups that the distribution and reuse of code among developers will instantly reduce man hours and costs. On the surface, the logic is sound, but in the trenches this attitude stifles the emergence of greatness.

There are instances, especially in the creation of a software product, where practical standards must be introduced. No programmer would argue that some process or design protocol should guide and influence code. If you must connect to a database, then a single method for maintaining the connection should belong to the application. If you must traverse an XML document, then a single library capable of serializing nodes into objects should be considered.

Yet, beyond these singular utilities that enhance productivity finitely, there should not be an instance where an entire set of processes are continually re-purposed. Do not misunderstand — a framework that constitutes the backbone of an application is obviously a set of processes that are continually re-purposed. However, these features are common enough to meet the general requirements of a variety of applications, and are ambiguous by nature.

Programming uniqueness

This is probably the most difficult point to communicate to any individual concerned only with numbers and budgets, but programming uniqueness into an application is an obligation. There is no need to architect a solution that is creative for the sake of creativity. Yet, unless you are in the business of product support, clients expect you to drive a wedge between themselves and competitors. Although you can filter code from previous projects as a starting point, changing specifications and interface designs requires a custom approach.

This uniqueness is beneficial, not only because it serves your clients, but because it forces programmers to think about solving unique problems. This is essential to the professional growth of any development staff. Without it, there is little room to learn, and complacency is implicitly encouraged.

Taking code out of context

The simple fact is that code reuse also puts little emphasis on context. Even if your client’s needs are astoundingly similar to the needs of many of your clients, the context will be different. As an organization, a client will have data structures unlike any other, environments that are configured inefficiently, and legacy applications that are downright ridiculous. Any experienced programmer knows that the time it takes to adapt a piece of code out of context will take longer than a fresh approach.

Given a piece of code that was a hand-me-down, it is rarely beneficial to reuse it unless tweaks will be sparse. Even then there are dangers associated with porting large chunks of code, including the introduction of security vulnerabilities, bugs and the loss of optimization.

Prohibiting optimization

Optimization is one of the few measurable characteristics of code quality. Programmers can argue about design patterns, the fine details of OO, and language-specific syntax, but the benefits of optimization can be backed up with hard data. Code reuse does not foster optimization, or even invite explorations into the possibility. More than anything, this prevents entry-level programmers from being trained by senior programmers because it is assumed their code is perfectly refined.

Although we do have a tendency to scoff unrelentingly at the majority of code crossing our path, scrutiny in limited quantities is a good thing. This critical approach to development produces a better programmer, which is what in turn actually reduces man hours and cost.

From http://blog.reindel.com/