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…
It is important to keep in mind that any software ends up being a living thing. Even if you know all the requirements up front, which you almost never do, they’re inevitably going to change down the road. Customers will want new features, business might pivot what they’re doing, and so on. It’s pretty much inevitable that the software will keep evolving. It’s key to recognize this and design things in modular fashion so you can evolve things in a sane way as the need for changes comes up. That said, I find you can start small and figure out what the MVP looks like, then go from there. You can draw out the bare minimum and then use that to interrogate the project manager to make sure it matches what they’re expecting.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
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…
It is important to keep in mind that any software ends up being a living thing. Even if you know all the requirements up front, which you almost never do, they’re inevitably going to change down the road. Customers will want new features, business might pivot what they’re doing, and so on. It’s pretty much inevitable that the software will keep evolving. It’s key to recognize this and design things in modular fashion so you can evolve things in a sane way as the need for changes comes up. That said, I find you can start small and figure out what the MVP looks like, then go from there. You can draw out the bare minimum and then use that to interrogate the project manager to make sure it matches what they’re expecting.