Snippet-Driven Development: My Snippets Are My Thinking Process

I want to tell you about a development technique called "Snippet-driven Development". I would not claim to have invented it, but I may credit myself with finding "a catch", which allows for it to be applied in teams of any size and of any professional composition. I have successfully implemented it at one of my previous workplaces, and brought it to all the companies at which I have worked in a managerial position ever since.

There are lots of different development techniques, with most famous being perhaps the test-driven development and the behavior-driven development. Any employed technique aims to solve some particular issues, which are either organizational or technical. Teams, suffering from insufficient testing, may reach for TDD. Teams, suffering from extensive overtesting without paying much attention to what is being tested and what the value (if any) of a particular test is, may also reach for TDD. Semi-technical key stakeholders with a vivid imagination may mandate BDD (and long-enough into the project, the architecture committee may attempt to define and standardize your own DSL flavor of Gherkin).

Two issues a technique may try to address are the developer feedback loop and the release cycle, and how to bring them to the bare minimum. Another less-discussed technique out there is called demo-driven development. A very agile both in letter and spirit, the premise of this technique is simple - demo as often as possible in small increments. Demo is better than a status update. Demo is actionable. Demo is presentable to non-technical stakeholders. And demo near equally means a shippable artifact. Sounds all good. There are problems though, which may arise in part from the scope of the demo. A demo requires quite a lot of effort, unlike the other stuff. Demo is bigger than a commit, which simply passes the CI/CD tests, and it also requires more organizational coordination to happen. It is also not clear, what exactly features, bugfixes and the likes should land into the demo.

Now, the natural aim would be to try to smooth the rough edges, while preserving all the benefits of the demo. And the solution may seem to be rather obvious, but there's some very small yet very important paradigm shift in thinking which has to happen for the snippet-driven development to become viable and valuable. We could obviously smooth the rough edges by reducing the scope (the usual managerial activity). We could invite fewer people to the demo, make it less formal. But this is not the case.

The premise of snippet-driven development is also simple: as evident from the name, when you have a task to complete, you write a small code snippet, that gets the job done for this task. Task should be rather small, which requires decomposition (again, an issue more of a managerial nature than of technical), so that just a few lines of code would be enough to move the task to "Done". But here's the catch: instead of incorporating the snippet into a larger codebase, you leave the snippet as is, and treat it as a fully self-sufficient standalone program. You would want to put a small README, have a test or two in place, which you may want to write in advance before starting writing the snippet (which is the key takeaway from TDD, very good on paper, but seldom works when dealing with large codebases while implementing a feature for a problem you have little understanding of). You demo the snippet, but you won't have to schedule a meeting, or even share your screen, since the snippet should be easy to run locally, and so the person performing the code review would be able to run it in an instant without your proactive help.

Next, when the snippet is finished, do not hesitate or wait - just pick up another task and implement another snippet. Again, do not incorporate it into larger codebase. The new snippet should not be based upon the previous one, and should not even be contextually aware of another snippet's existence.

A SEO spam sentence: this way has its benefits. If you're working on a feature that requires multiple snippets of code, you can release each snippet as soon as it's ready, instead of waiting for the entire feature to be finished. If you have an idea for a new feature, you can implement it in a snippet and release it immediately, instead of waiting for the rest of the team to sign off on your bikeshedding. This way, you can get feedback on the idea sooner and decide whether or not it's worth pursuing. It also allows you to speculate on how the snippet would fit into a larger codebase without yakshaving, since you need your snippet to be demo-actionable. You also don't have to wait to get the psychological satisfaction of the task being done (which is very important). Another second-order benefit is that this technique could be particularly useful for less-experienced teams that are starting out with a new codebase or technology stack, as it would allow them to get started quickly and learn as they go.

So, the key points are:

• decompose tasks (if possible)
• small snippets
• treat as small programs
• don't incorporate them into larger codebase just yet
• switch to another snippet

It must be obvious, though: snippet-driven development does not cancel the fact, that snippets should eventually become part of your software. Snippet-driven development is the middle ground for waterfall being too waterfally and agile being even more nonsensically waterfally. The snippet is your planning phase. The technical discussion, should it happen, does not span millennia of projected work.

[Fineman's] notes aren't a record of [his] thinking process. They are [his] thinking process

The conclusion: overall, I think snippet-driven development is a great way to work if you're able to keep on top of things. It mandates discipline, but I would say the benefits are rather convincing, and I haven't really experienced any pushback from the teams. It can help you move faster and get feedback sooner, which is always valuable.