• Why are we doing it?
• Why are we doing it this way?
• Why are we doing it now?

Not everything can be the same, though. That's why you're building two different application systems -- they address two different sets of requirements. But that doesn't mean they can't share many of the same basic components.

The trick here is to make your components configurable, so they can serve more than one purpose without having to be duplicated. Take for example the process of recording time spent on an activity. Think of the number of applications for this basic process. Programmers record time against projects. Mechanics record time against repair orders. Attorneys record time against cases or clients. Employees log their hours on time cards. The list is virtually endless -- it's a very basic business component of a number of application systems.

Assuming that you've already embraced the fundamental concept of separating out your presentation layer from your business objects and your business objects from your data access layer, you already know that you can swap out one system's "look and feel" for another or unplug one application's datasource and plug in another, yet still reuse the same business component.

That's a great first step along the road to software reuse, but you are still going to have issues if you try to use a timekeeping component designed for automotive repair to keep track of developers' time on software products.

Robust reusable components are externally configured and loosely coupled. That means that if you want to make a reusable time-keeping application, you have to place the knowledge of what it is that you are recording time against outside of the component (externally configured). When you assemble an application system from existing reusable components, you first select your components, and then configure them for your purpose. What you do not do is alter the component, or make a copy of it -- you just reuse it. You couple your timekeeping component to your other application system functions through configuration, not through programming.

Human intervention kills productivity and introduces defects
As with most fundamental truths, the foundation of the case against cloning is a very simple concept: altering, in any way, something that works is a bad thing. The general rule is simply this: don't touch!

Human involvement is the biggest limiting factor in any endeavor. Before there were PCs or photocopy machines in an office, if you wanted a second copy of a document, you had to type out another one just like the first (yeah, there was carbon paper, but subsequent carbons looked far worse).

The limiting factor in how many copies you could crank out in a specified time was the speed of the typist. The faster one could type, the more documents one could generate. Still, since each one was a unique work product, and there was no guarantee that the copies were, in fact, exact replicas of the original.