3 ms·

I think the issue most of the time is that you only start with two states, and you can avoid complexity by not implementing a FSM. But suddenly requirements ch

I think the issue most of the time is that you only start with two states, and you can avoid complexity by not implementing a FSM. But suddenly requirements change, and you have 4 or 5 new states that could go back and forth. The original approach ends up being way more complex than implementing a FSM in the first place; or even, than implementing the FSM when you add a third state.

vemv 3y ago
When they seemingly need go "back and forth" I typically consider it good timing to create a new instance (object, or DB row) instead of keeping mutating the same instance. e.g. one can consider a re-purchased return simply a new purchase, instead of doing a purchased->returned->purchased transition.
Balladeer 3y ago
This "suddenly requirements change" is why I get instantly wary whenever I see a boolean column like `completed` in a design. Sure, you start with two explicit states. But then you add `deleted` and now you have four states, whether you know it or not. Then there's talk of adding a third boolean column, and folks are wondering what it _means_ to be "deleted" but not "completed" and whether that is a valid state, and pretty soon the team is reinventing the concept of a state machine without any of the vocabulary that makes it straightforward.
giraffe_lady 3y ago
Yeah or even more insidious when a new state looks like, and so is modeled as, just a special case of one of the original two. As a mentor said to me early in my career "every functioning business system is a state machine, but the only ones that are easy to work on are where they knew that from the beginning." Most systems I've worked on end up with one of the "original" states being a catchall or misc type entity that could carry any number of other meanings depending on timing and context. A lot of legacy code work in my experience is actually a game of "find and name the states" when they're spread out across multiple systems, written at different times and with different understandings of the broader system, and with different methods to track and modify them.

vemv 3y ago

When they seemingly need go "back and forth" I typically consider it good timing to create a new instance (object, or DB row) instead of keeping mutating the same instance. e.g. one can consider a re-purchased return simply a new purchase, instead of doing a purchased->returned->purchased transition.

Balladeer 3y ago

This "suddenly requirements change" is why I get instantly wary whenever I see a boolean column like `completed` in a design. Sure, you start with two explicit states. But then you add `deleted` and now you have four states, whether you know it or not. Then there's talk of adding a third boolean column, and folks are wondering what it _means_ to be "deleted" but not "completed" and whether that is a valid state, and pretty soon the team is reinventing the concept of a state machine without any of the vocabulary that makes it straightforward.

giraffe_lady 3y ago

Yeah or even more insidious when a new state looks like, and so is modeled as, just a special case of one of the original two. As a mentor said to me early in my career "every functioning business system is a state machine, but the only ones that are easy to work on are where they knew that from the beginning." Most systems I've worked on end up with one of the "original" states being a catchall or misc type entity that could carry any number of other meanings depending on timing and context. A lot of legacy code work in my experience is actually a game of "find and name the states" when they're spread out across multiple systems, written at different times and with different understandings of the broader system, and with different methods to track and modify them.