If reuse has any potential as a silver bullet for successfully delivering business and technology value, it will almost certainly rely on our ability to clearly and unambiguously characterize the problem space so that the corresponding subset of pre-built validated solutions that target this domain (the solution space) are visible. Only then can we even make the choice to reuse.

In other words, we can't reuse something if we don't know it is a fit for our needs, or worse, that a previous solution even exists.

Consequently, lack of a regular reuse routine starts with the fact that we have, as an industry, such poor requirements discipline and rigor, if we do them at all. It is hardly surprising, therefore, that we fail to recognize how closely our current problem may actually be to one that has been solved before. This lack of awareness together with our innate invention-is-more-fun bias quickly justifies our need to rebuild the solution.

Another invention … another solution that will not be saved and not catalogued for reuse. And, of course, another solution whose cost and risk are exorbitantly and needlessly high.

So, it again comes back to requirements. How often do we find that the root cause or critical success factor in some important software engineering issue rests with this thing called requirements (and the process for capturing and integrating them into the necessary work-products)? And yet, this facet of software engineering (one might even say, seminal, or foundational facet) is given embarrassingly short shrift.

No area of software engineering has received less attention than requirements.

Yet it is central to everything we do. It defines quality. It defines success.

(A digression may be helpful. Requirements and its role in software engineering is not well understood. But, the term as used here is not intended to imply any particular representation or manifestation, or even logical sequence, but rather simply a characterization of the problem or opportunity that is sufficiently unambiguous and complete so that someone other than the requirements owner can reliably obtain and validate a successful solution, and know it. This characterization is independent of tool sets, database repository designs, document templates, and may be captured before, during, and after the software solution has been approximated. Two crucial issues remain, however: (1) they are captured in a rigorous way, and (2) they are assets of, and owned by, the corresponding user or customer.)

On the positive side of the reuse equation it turns out that there are only a handful of unique business problems and a correspondingly astonishingly small set of software solutions. Most problems that any of us will ever see have been successfully solved before, often many times. (We will perhaps talk more later about this relatively small universe of business and technology frameworks, architectures, classes, templates, etc. that, in fact, span 99% of all business and technology situations that any of us will ever encounter. Recognizing this catalog of templates will be an important piece of the puzzle.) This says, however, that if we ever get the chance, virtually every technology project, if not---soon in fact---every one, can substantially benefit from reuse.

Further, we had observed earlier that one enormous advantage of the reuse idea is that it reduces the number of steps between problem or opportunity recognition and tangible value experienced by the targeted customer or user. We also pointed out that fewer steps are always better.

So, let's start with zero steps.

In other words, the definition of the problem is the solution. Problem = Solution. Done.

And, of course, if we did in fact capture the requirements in a rigorous way and were also in possession of a special computer whose instruction set included the requirements "language", then in one step we capture the requirements which can now be executed on this special computer to directly solve this problem and deliver its intended value.

Wow.

Talk about silver bullets.

All we need now is to focus our energy and talent on finding a way to rigorously capture requirements and then on defining this special computer that will execute these requirements.