<reponame>QubitPi/jersey-fundamentals
\chapterimage{chapter_head_2.pdf}

\chapter{Avoid Duplication}

\section{DRY}

Unfortunately, knowledge isn't stable. It changes—often rapidly. Your understanding of a requirement may change following a meeting with the client. The government changes a regulation and some business logic gets outdated. Tests may show that the chosen algorithm won't work. All this instability means that we spend a large part of our time in maintenance mode, reorganizing and reexpressing the knowledge in our systems.

Most people assume that maintenance begins when an application is released, that maintenance means fixing bugs and enhancing features. We think these people are wrong. Programmers are constantly in maintenance mode. Our understanding changes day by day. New requirements arrive as we're designing or coding. Perhaps the environment changes. Whatever the reason, maintenance is not a discrete activity, but a routine part of the entire development process.

When we perform maintenance, we have to find and change the representations of things—those capsules of knowledge embedded in the application. The problem is that it's easy to duplicate knowledge in the specifications, processes, and programs that we develop, and when we do so, we invite a maintenance nightmare—one that starts well before the application ships.

We feel that the only way to develop software reliably, and to make our developments easier to understand and maintain, is to follow what we call the DRY(Don't Repeat Yourself) principle:

\begin{remark}
EVERY PIECE OF KNOWLEDGE MUST HAVE A SINGLE, UNAMBIGUOUS, AUTHORITATIVE REPRESENTATION WITHIN A SYSTEM.
\end{remark}

\begin{marker}
On duplicated codes, ask code author to remove it
\end{marker}

\section{How Does Duplication Arise?}

Most of the duplication we see falls into one of the following categories:

\begin{itemize}
    \item \textbf{Imposed duplication} Developers feel they have no choice—the environment seems to require duplication.
    \item \textbf{Inadvertent duplication}  Developers don't realize that they are duplicating information.
    \item \textbf{Impatient duplication}  Developers get lazy and duplicate because it seems easier.  
    \item \textbf{Inter-developer duplication}  Multiple people on a team (or on different
teams) duplicate a piece of information.
\end{itemize}
