5 ms·

That was a really good read. I appreciate the detail that the writer went into describing his investigative process. Let the warning be heard loud and clear: s

by kache_ 6y ago

That was a really good read. I appreciate the detail that the writer went into describing his investigative process. Let the warning be heard loud and clear: state is the devil

Jtsummers 6y ago
State isn't the devil. Nor is it a necessary evil. State is essential to many, if not most, interesting applications. Poorly managed state or ad hoc state machines are the devil. Once you model your system properly as a state machine, many of these issues fall out during the initial design and development (not to say they won't happen anyways, but this mitigates many of the issues). If you design your system so that whatever variables define your state are mutated together to ensure your invariants hold, this helps a lot with addressing poorly managed state. And if you can (you can't always) use a system which is aware of state machines as part of the design then you can mitigate the ad hoc state machine part.
- bob1029 6y ago
  I would go further and say that the modeling isn't even a big deal (in terms of state machine complexity) as long as you are enforcing immutability at your domain boundary. If only domain methods are able to mutate state, it's a lot easier to find where bugs might be hiding. If any consumer of your domain model can mutate anything in any way it sees fit and then invoke some generic UpdateState(model) method, then you have a much bigger problem. Put differently, as long as you have good accountability of all the things that can change the state and are comfortable with how that set of things operates, then you are probably in a decent position.
  - Jtsummers 6y ago
    That's fair, and is similar to what I would've written if I'd elaborated more on my "poorly managed state" comment. If you apply good modular/OO principles you at least constrain where state is managed in a way that makes writing, maintaining, and testing your system more tenable without an explicit model.
agency 6y ago
* her[1] investigative process [1] https://twitter.com/natashenka https://twitter.com/natashenka
- buckminster 6y ago
  It's an easy mistake to make because the top of the article says > Posted by Natalie Silvanovich but the bottom says > Posted by Ryan The latter is just the blogspot username though. It's quite scruffy.
- deleted 6y ago
  [deleted]

by kache_ 6y ago

That was a really good read. I appreciate the detail that the writer went into describing his investigative process. Let the warning be heard loud and clear: state is the devil

Jtsummers 6y ago

State isn't the devil. Nor is it a necessary evil. State is essential to many, if not most, interesting applications. Poorly managed state or ad hoc state machines are the devil. Once you model your system properly as a state machine, many of these issues fall out during the initial design and development (not to say they won't happen anyways, but this mitigates many of the issues). If you design your system so that whatever variables define your state are mutated together to ensure your invariants hold, this helps a lot with addressing poorly managed state. And if you can (you can't always) use a system which is aware of state machines as part of the design then you can mitigate the ad hoc state machine part.

bob1029 6y ago
I would go further and say that the modeling isn't even a big deal (in terms of state machine complexity) as long as you are enforcing immutability at your domain boundary. If only domain methods are able to mutate state, it's a lot easier to find where bugs might be hiding. If any consumer of your domain model can mutate anything in any way it sees fit and then invoke some generic UpdateState(model) method, then you have a much bigger problem. Put differently, as long as you have good accountability of all the things that can change the state and are comfortable with how that set of things operates, then you are probably in a decent position.
- Jtsummers 6y ago
  That's fair, and is similar to what I would've written if I'd elaborated more on my "poorly managed state" comment. If you apply good modular/OO principles you at least constrain where state is managed in a way that makes writing, maintaining, and testing your system more tenable without an explicit model.

agency 6y ago

* her[1] investigative process [1] https://twitter.com/natashenka https://twitter.com/natashenka

buckminster 6y ago
It's an easy mistake to make because the top of the article says > Posted by Natalie Silvanovich but the bottom says > Posted by Ryan The latter is just the blogspot username though. It's quite scruffy.
deleted 6y ago
[deleted]