Not long ago, I had a discussion with a colleague. I told him that if he can’t explain his planned work to his peers, he should probably work on his plan. Kind of paraphrasing Richard Feymann:
If you can't explain something to a first year student, then you haven't really understood it.
[https://en.wikiquote.org/wiki/Talk:Richard_Feynman]
The problem seems easy enough, but in this context the problem was also finding what to do. Kind of a “Full Stack Engineer” for a whole slice of a domain. Maybe “Full Domain Engineer”?
As a Full Domain Engineer getting your list of tasks is not merely structuring around ready made requirements, but finding those requirements in the first place. This needs a lot of communication. To put all that information into a form that can be understood and be worked with we require models = representations.
Event Storming helps with some definitions and ways to put them together. (see https://miro.com/miroverse/event-storming/ for a nice walk-through). But the transition from a model to a list of tasks is pretty hard. Some problems I had were the following:
- Leaking technical decisions, especially past ones, into the model. For example some events which only occur because of a workaround.
- Document decisions on the semantics of the model. Even though I feel like a wiki page should do, that failed me on follow ups.
- Differentiating between the domain and technical things. That was especially hard, when my team was providing technical infrastructure. The domain is infrastructure, but the technical things are the infrastructure. So what is the domain?
- Our Brains need time to process. Don't transition into task mode right after a modelling session.
Last but not least, I think the whole modeling session is to inform, not to create tasks. Finally we need tasks, but I always felt they are created way too early.
Top comments (0)