Re:Code only says what it does
by ThomasDeutsch on Tuesday July 07, 2020 @02:13AM
(#23756235)
The "why" can be expressed in code.
Think of "Event Storming".
A great way to talk about the "why" and to grow an understanding of how a problem can be solved.
The result can be multiple "flows" that describe a series of events from the first command to the expected outcome.
We have the option to directly translate a flow to code.
And by keeping the flow in one place, we also keep a direct mapping from our code to the EventStorming-results.
The "why" will not be lost.
The code can contain multiple flows and every flow can have a scenario-like description like:
"the user is able to select a product"
This is what my passion is all about.
To keep the "why" in one place.
This also enables better collaboration between multiple disciplines (like UX <-> DEV)
Think of "Event Storming". A great way to talk about the "why" and to grow an understanding of how a problem can be solved. The result can be multiple "flows" that describe a series of events from the first command to the expected outcome.
We have the option to directly translate a flow to code. And by keeping the flow in one place, we also keep a direct mapping from our code to the EventStorming-results. The "why" will not be lost. The code can contain multiple flows and every flow can have a scenario-like description like: "the user is able to select a product"
This is what my passion is all about. To keep the "why" in one place. This also enables better collaboration between multiple disciplines (like UX <-> DEV)
This is the idea behind scenario based programming. I am working on an open source project: https://github.com/ThomasDeutsch/flowcards
Write me a line if you would like to get involved.
Have you found other solutions for this problem?