The Gravel-Road-to-Highway Pattern

Imagine a practice that has delivered work for many customers over several years. Each engagement produced code, and some of that code solved problems that will come up again. A natural question follows: what does the practice actually gain by holding on to that code in an organized way? This article answers that question, and also explains why a solo operator who never grows past one client can still benefit from the same habit.

The source treats this accumulated code as a concrete asset rather than a side effect of the work. Slices pile up naturally as engagements close. Whether they become valuable depends on whether the practice keeps them in a form that a later engagement can pick up and use. Keep that condition in mind as you read, because it drives everything that follows.

The definition contains two details that matter. The first concerns the source of the contents: they come from work already completed for real engagements, not from code written in advance as a generic exercise. The second concerns the purpose: a slice in the library is valuable because it can be taken, modified, and reused. A folder of old code that nobody can adapt is not yet a library in this sense.

Library contents are not produced in a separate step. They are the by-products of individual customer engagements. When a piece of work for a customer is complete, the part of it that solved a reusable problem can be captured as a slice. The source emphasizes that this accumulation happens as engagements close, so the library grows as a natural consequence of normal delivery work.

Capturing is a deliberate act, though. Slices pile up naturally, but they only become a library when the practice keeps them in an organized form that a later engagement can use. The next diagram shows the full path, from finished engagement work to the template that a future customer benefits from.

Reading the pipeline left to right traces the pattern. The first engagement's work is not finished as soon as the customer accepts it. Its value continues if the practice captures it, and that captured material then supports the next template.

The growth of a library is easiest to see by following one slice through time. Consider a hypothetical practice. In the first engagement, a customer needs a particular piece of functionality. The practice builds it, the customer accepts it, and the engagement closes. At that point the slice exists, but it is only one of many finished artifacts. Its value depends on the practice recognizing that the reusable part is worth keeping.

The slice is then captured into the library in a form that someone can later find and pick up. When a new customer arrives with a related need, the practice does not start from a blank page. It starts from the captured slice, which serves as a working prototype. The slice is taken, modified for the new customer's situation, and reused. That adapted version is what feeds the template that later work builds on.

The before and after views show the same underlying slice. The adapted version differs in the parts that the new customer's situation requires, and it is still recognizably the captured slice. That recognizability is why the library is useful: the practice gets a head start without pretending the old work fits the new customer exactly as it was.

The source names two specific advantages of a library. They differ in kind. One affects how quickly the next engagement can begin. The other affects how the practice communicates with a customer before any code exists for that customer. Both depend on the library being organized so that its slices can actually be used.