Capturing Slices From Completed Engagements
A slice library is a collection of reusable code slices accumulated from past engagements and meant to be adapted for new customers.
Why a Practice Keeps Its Old Code
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. Most of it, once the engagement closes, sits in a place where nobody looks at it. The question this article answers is what a practice actually gains by holding on to that code in an organized way.
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. The same habit also matters for a solo operator who never grows past one client, because the reuse logic does not depend on the size of the practice.
What a Slice Library Holds
A slice library is a collection of reusable code slices accumulated from past engagements and meant to be adapted for new customers.
The definition contains two details that matter. The first is the source of the contents: they come from work already completed for real engagements. The second is the purpose: a slice in the library is valuable because it can be taken, modified, and reused. Each part of that definition carries weight. Remove the word completed and you lose the idea that the library is built from proven work. Remove the word adapted and you lose the idea that a slice is a starting point rather than a finished product for one customer.
Read the diagram from the top down to see what the library is made of: a collection of slices. Read it from the bottom up to see where each slice came from: a specific completed engagement. Read it from left to right on the lower path to see how a slice travels forward into new work. The library is the place where these three relationships meet.
Following One Slice Through Time
The growth of a library is easiest to see by following one slice through time. The example below uses a hypothetical practice. The customer names and details are invented for illustration; only the principle comes from the source. Keep the steps in order, because the value of the slice depends on each stage happening before the next one.
One slice moving from a finished engagement into a template
A hypothetical practice finishes work for a first customer. One piece of that work solves a problem that will come up again. Trace what happens to that piece after the customer accepts the work.
- 1The engagement produces working code
The first customer's engagement yields code that solves a real problem. At this point it is only part of one customer's delivered work.
- 2The customer accepts the work
The engagement is accepted, but the source notes that the first engagement's work is not finished as soon as the customer accepts it. Its value continues only if the practice captures it.
- 3The practice captures the slice
The practice keeps the reusable piece in an organized form, so it becomes a slice in the library rather than remaining buried in the closed engagement.
- 4A new customer begins from the slice
When a second customer has a similar need, the practice starts from the captured slice instead of a blank page. The slice is taken and modified for that customer.
- 5The adapted slice feeds a future template
The captured material supports the next template. This is the step where the gravel-road-to-highway pattern becomes concrete: an initial effort has become an input to later work.
The single slice went from a closed engagement, through the library, into a new customer's work, and finally into a template. Its value came from the capture and the adaptation, not from the first customer's acceptance alone.
In the pipeline, the slice first changes state at the capture step. Before capture, it is part of a finished engagement. After capture, it is a library entry that a later engagement can use. The second change happens at the template step, where the adapted slice becomes an input to a template. The earlier steps are necessary for that final step to happen.
Two Practical Benefits
The source names two specific advantages of a library. They are different in kind. One affects how fast the next engagement can begin. The other affects how the practice talks to a customer before any code exists for that customer. Keeping the two separate helps when deciding why a practice should invest in capturing slices at all.
What Carries Over to a New Customer
The main confusion about reuse is assuming that a slice transfers to a new customer unchanged. The source's definition says slices are meant to be adapted for new customers, so reuse means starting from a slice and modifying it. The table below separates what is typically kept from what must be adapted for each engagement. This split is a teaching summary built on the source's emphasis on adaptation rather than a complete list.
| Aspect | Carried over from the slice | Adapted or left out for each new engagement |
|---|---|---|
| Starting point | A working prototype the practice has already built | The specific shape of the new customer's need |
| Customer details | None; these are not part of the reusable core | Every customer-specific name, detail, and requirement |
| Credibility | The practice can point to a delivered example | The preview must be stated for this customer's case |
| Purpose | The slice is valuable because it can be taken and reused | The reuse decision for each new engagement |
What is reused from a slice across customers, and what must be adapted or left out
Common mistake Treating any folder of old code as a slice library
What it looks likeA practice keeps every finished project in one directory and calls it its library.
Why it failsThe source's definition requires slices that can be taken, modified, and reused. Unadaptable old code does not meet that purpose.
Do this insteadCapture only the pieces that can be adapted, and keep them in a form a later engagement can pick up.
Common mistake Pasting a slice into a new customer's work without changing it
What it looks likeA slice built for one customer's needs is delivered unmodified to a second customer.
Why it failsSlices are meant to be adapted for new customers, so an unmodified slice ignores the purpose the definition gives it.
Do this insteadStart from the slice, then modify it for the new customer's specific needs.
Common mistake Thinking the first engagement's value ends at acceptance
What it looks likeThe practice considers a project finished once the customer signs off and never captures its reusable parts.
Why it failsThe source states that the first engagement's work continues to have value if the practice captures it.
Do this insteadCapture the reusable slices as part of closing an engagement.
Common mistake Believing only large practices with many customers can benefit from a library
Common mistake Assuming a customer-specific preview needs no customization
What it looks likeA practice shows a second customer the exact outcome from a slice built for a different customer.
Why it failsThe second benefit depends on giving a credible view of what will be built for that customer, which requires adapting the view to them.
Do this insteadDescribe the preview in terms of the new customer's need, using the library slice as evidence.
Practice Tracing a Slice
A hypothetical practice finishes a first engagement and produces a piece of code that solves a problem a later customer will likely have. Describe, step by step, how that piece can become an input to a future template. For each step, name the change in its status and say which benefit of the library, faster starting or a credible preview, that step supports.
Hints
- Start from the moment the engagement is accepted, but remember that acceptance alone does not finish the slice's value.
- Look for the step where the practice keeps the slice in the library, since the source ties the slice's future value to capture.
- Each benefit should map to a different moment: one before the new engagement's code, one at the start of that engagement.
Key Takeaways
- A slice library is a collection of reusable code slices accumulated from past engagements and meant to be adapted for new customers.
- Its contents come from work already completed for real engagements, and a slice is valuable only if it can be taken, modified, and reused.
- The library gives a practice two different benefits: a faster start from a working prototype, and a credible view of what will be built for a customer before code exists for that customer.
- A slice can become an input to a future template once it is captured, adapted, and reused; the library is the operational form of the gravel-road-to-highway pattern.
- Reuse means starting from a slice and adapting it for each new customer, not transferring it unchanged.