How we caved and created a roadmap

In June 2021 I wrote a post proclaiming that we don't have a roadmap and that we don't need it. And the argument we build what we need only when we need it still holds... Only for the engine though.

If we take a look at an abstract design.

1. Tracepaper is our modeling studio, a form-based visual tool to map out your application domain.
2. Tracepaper will export a technical model, this model is XML based in what we call Draftsman Modeling Language.
3. The Draftsman Engine converts this technical model into code.
4. The generated code is stored in a GitHub repository.
5. An AWS CodePipeline will build and deploy the application.

The engine has one function, convert the technical model into code. It is literally a stack of enablers on top of enablers. Mapping concepts to implementations. For example, we need the concept of state. We decided to use Event Sourcing for maximum flexibility. We design XML structures to model events and event handlers (we sometimes call them glorified setters). And we implement code that converts the designed XML structure into Python code and Cloudformation magic.

That's it, it doesn't do anything unless you feed it some specific XML. And that is what we did, we started modeling the Tracepaper application by writing the XML by hand. And that is how the engine grew. During the modeling of Tracepaper, we encounter missing concepts (querying, integrations to external APIs, event-chain tracing, and many more.) And that is how the stack of enablers grew. We built what we need when we need it.

In the generator report you can see the concepts mentioned, how many lines XML are used to describe the model and what is generated. In the screenshot you can see the generator report for the application that is modelled during the tutorial.

If you are curious, I also put a report online after converting the Tracepaper model into code. If you compare the two reports (and ignore the fact that Tracepaper has a bigger domain than the tutorial) you will notice that Tracepaper uses concepts that are not available to our clients. And there is our backlog...

The engine can do many fancy things and we even started to forget some of the features. So we decided to write down all the things that we need to model into Tracepaper, and this became some sort of a roadmap. So there you have it, the engine are enablers and we make it up as we go. But Tracepaper should make those enablers understandable to humans, and that is something we can plan.

Our velocity varies, but at least we have everything on a Trello board to keep track of the things we should do.