How to work with unknowns
When it comes to concrete implementation plans, there can be no open questions. But known unknowns can and should be part of the process of planning multiple gameplans ahead.
A workstream is a simple way to tie multiple gameplans together. When writing a workstream, the engineer plays more of a product management role; they describe a high-level sequence of changes which should add up to a fully-formed feature.
When it comes to concrete implementation plans, there can be no open questions. But known unknowns can and should be part of the process of planning multiple gameplans ahead.
All the patches in a gameplan make up, together, a single coherent change, and represent a single atomic addition to the system.
But we need the ability to plan into the future and to build changes on top of each other.
Just as importantly, we need to designate safe stopping points, where the system is in a coherent state. Workstreams are divided into milestones, by definition a point where some degree of value has been delivered and the team can stop and evaluate what's most important to do next.
Pantagruel's
built-in write-spec skill guides the user through
the creation of a formal specification for the feature
described in the workstream.
The result is a type-checked, model-checked spec of the behaviour of the feature. It is guaranteed to be free of (certain types of) ambiguities and contradictions, making it a more reliable basis of correctness to use when creating gameplans and executing them.
Gameplans and their execution are all about technical implementation; write the spec at the workstream level to deal primarily with domain concepts. The spec will describe what should be true about the feature, not about the internal state of the application.
Just as importantly, this is also the time for the engineer to become an expert in the feature at the domain level. The engineer will emerge with a clearer understanding of the core concepts and actions that make the feature up.