The Small Ovens of Software

Many of us have heard the Thanksgiving turkey story: A child is learning how to prepare the family Thanksgiving meal. Every year, the turkey gets cut in half before it goes into the oven. One year, the child asks why.

Nobody knows. Mom learned it from Grandma. Grandma learned it from Great-Grandma. Eventually someone traces the tradition back far enough to discover the answer. Great-Grandma’s oven was too small. The instruction survived. The reason did not.

Of course, this does not happen in every family, but we recognize it because we’ve all seen versions of it in our own lives. Organizations are full of small ovens—constraints that require special handling, though no one remembers why.

The Written Process and the Lived Process

Every organization has documentation. Requirements documents. Process flows. Functional specifications. Architecture diagrams. Standard operating procedures.

Most organizations also have stories:

• “Don’t touch that table.”
• “That report doesn’t work quite the way the documentation says.”
• “Finance uses that field differently than intended.”
• “We tried fixing that once. It broke three other things.”

Those statements rarely appear in requirements documents, yet they often contain some of the most valuable knowledge in the organization.

The documentation tells us what we intended to build. The stories tell us what happened after reality got involved.

I inherited one of these “small ovens” early in my work with a long-running operational system. The advice was simple: “Don’t change that table unless you absolutely have to.” At first it sounded like ordinary institutional caution. Over time I discovered part of the reason. The table sat at the center of a web of reports, integrations, and business processes that had accumulated over many years. Every visible dependency was documented eventually, but I was never completely certain I had found them all.

That uncertainty changed how I worked. Before making structural changes, I looked for ways to extend the system downstream, added validation around existing behavior, and treated any modification to the core model as a last resort. The constraint was not “never improve the design.” It was recognizing that the cost of being wrong could extend far beyond the code I was editing.

Even today, I cannot say I uncovered every original reason for that warning. Some of the history had already disappeared with earlier projects and the people who worked on them. The lesson was not that the table was untouchable. It was that inherited constraints often preserve knowledge that has not yet been written down.

The Oral Tradition of Software Engineering

For most of my career, software engineering has had a strong oral tradition. Developers learned from developers. Business analysts learned from subject matter experts. Architects learned from the people who had already stepped on the land mines.

A large portion of what made systems work was passed from person to person through conversations. Not because documentation was ignored. Because some knowledge is difficult to capture in a specification.

A functional specification can describe a field. It struggles to explain why that field was added after a production incident twelve years ago, why everyone is nervous about removing it, or why an apparently simple change has failed three times before.

That context often lives in people rather than documents.

The Gap

For years, many organizations treated documentation as the solution. If we document enough, future generations will understand the system. The problem is that systems keep changing. Businesses change. Regulations change. Technology changes.

Documentation captures a moment in time while the organization continues moving. The result is a gap between the documented process and the lived process. Most of us have worked in systems where the documentation was technically correct and practically wrong.

The organization evolved. The documents did not.

A New Opportunity

One of the more interesting uses of GenAI has nothing to do with generating code. For the first time, we have tools that can help preserve conversations at scale without hiring an army of transcribers.

Meeting summaries. Design discussions. Architecture reviews. Decision logs. Questions and answers. Lessons learned. The reasoning behind the decisions.

This does not replace documentation. If anything, good documentation becomes even more important. Weak documentation becomes easier to spot.

What changes is that we no longer have to rely exclusively on static documents that are approved, archived, and forgotten. We now have the ability to preserve some of the context that previously disappeared into conference rooms, hallway conversations, and retirement parties.

That opportunity comes with a hard cultural problem. Even when people do not distrust GenAI, they may have good reasons to distrust how their employer might use captured conversations. Preserving institutional memory will require serious governance around consent, privacy, retention, access, and the ability to correct the record, because people misspeak, change their minds, and think out loud. This may turn out to be the hardest part.

Both Matter

I don’t believe the future SDLC will choose between documentation and conversation. We need both.

• Documentation captures intent and records what decision was made.
• Conversation captures context and often explains why.

As experienced technologists retire, organizations face a choice. They can allow decades of context to walk out the door, or they can find ways to preserve more of the reasoning, stories, lessons, and hard-earned knowledge that helped their systems survive in the first place.

Because somewhere in nearly every enterprise, there is still a small oven. And sooner or later, somebody is going to ask why we are still cutting the turkey in half.