One time, we were drawing a state diagram of how the core loop in our application should behave. So, you know, first you have the preparation state, then when that succeeds, you go to the getting-things-ready state, then into the actual doing-things state, then the result-reporting state and so on. So, there was exactly one happy path.
Then we figured, we should also diagram all the error scenarios. If an error occurs in the preparation state, we should transition to the result-reporting state. But if an error occurs in the getting-things-ready state, we’ll need to go to an intermediate cleanup state before we go to the result-reporting state, and so on.
As we added more and more error paths, the arrows had to curve more and more, until the whole diagram eventually looked like an onion. That’s when I knew, we were doing real software engineering. 🙃
I find making a state machine diagram before actually implementing an app is a really good approach because it forces you to think through the failure cases up front. What often happens toherwise is that you end up focusing on the happy case, and then error handling ends up being bolted on as you discover failure cases in production. This article is a great read on the subject https://shopify.engineering/17488160-why-developers-should-be-force-fed-state-machines
I mean, yeah, I wrote it kind of humorously up there, but I do actually think state diagrams are a good idea and modelling the known error paths is part of real software engineering.
However, I’ve never been in a project where anyone knew nearly enough about what we’re supposed to build, to be able to draw a state diagram before we got started. We would rather do a refactoring halfway through and then we would design a state machine to fit the requirements…
One time, we were drawing a state diagram of how the core loop in our application should behave. So, you know, first you have the preparation state, then when that succeeds, you go to the getting-things-ready state, then into the actual doing-things state, then the result-reporting state and so on. So, there was exactly one happy path.
Then we figured, we should also diagram all the error scenarios. If an error occurs in the preparation state, we should transition to the result-reporting state. But if an error occurs in the getting-things-ready state, we’ll need to go to an intermediate cleanup state before we go to the result-reporting state, and so on.
As we added more and more error paths, the arrows had to curve more and more, until the whole diagram eventually looked like an onion. That’s when I knew, we were doing real software engineering. 🙃
I find making a state machine diagram before actually implementing an app is a really good approach because it forces you to think through the failure cases up front. What often happens toherwise is that you end up focusing on the happy case, and then error handling ends up being bolted on as you discover failure cases in production. This article is a great read on the subject https://shopify.engineering/17488160-why-developers-should-be-force-fed-state-machines
I mean, yeah, I wrote it kind of humorously up there, but I do actually think state diagrams are a good idea and modelling the known error paths is part of real software engineering.
However, I’ve never been in a project where anyone knew nearly enough about what we’re supposed to build, to be able to draw a state diagram before we got started. We would rather do a refactoring halfway through and then we would design a state machine to fit the requirements…