Back end is full of hidden workflows(unmeshed.io)
unmeshed.io
Back end is full of hidden workflows
https://unmeshed.io/blog/your-backend-is-full-of-hidden-workflows
7 comments
Why is 'workflow' something special? Most/all code is workflows; there are many 70s programming books that show all code as workflow diagrams. How is it hidden? Or did we, as often is the case, change the definition? Not according to Google/Gemini anyway.
"This Is Exactly What Unmeshed Is Built For"
This feels spammy.
This feels spammy.
are people really writing workflows without knowing it?
or just making tradeoffs that its not complicated enough to need a workflow yet, then have troubles scheduling the move once it gets more complicated?
or just making tradeoffs that its not complicated enough to need a workflow yet, then have troubles scheduling the move once it gets more complicated?
I'm willing to bet that many start off without any notion of workflows thinking they're not going to need that or not thinking at all, and then add complexity step by step until it's an unimaginable tangled mess.
This is why so many small businesses (or even small departments in a large enterprise) start as a "simple" spreadsheet. Then it gets modified to cope with all the edge cases that crept in during the years until it is this huge horrible ball of mud that the business will crash & burn if the original author takes a day off.
Additionally, many companies have 3 sets of rules that they follow:
1. The one written down in the policy & procedures manual.
2. What the manager thinks happens.
3. What the people (who actually do the work) actually do.
In a perfect world, all 3 are the same. Far too often, when automating business processes, I'd run into the conflict. If you implement #1, on paper the project succeeds but it can't do what it is needed to do. If you implement #2, the mismanagers are happy, but it still can't do what it is needed to do. If you implement #3, the mismanagers won't pay because it doesn't meet the specs in their minds (nor the ones written down).
If you have good business analysts, you can/will discover the mismatch before too much time, sweat, money and development have been spent paving the wrong cow-paths.
Additionally, many companies have 3 sets of rules that they follow:
1. The one written down in the policy & procedures manual.
2. What the manager thinks happens.
3. What the people (who actually do the work) actually do.
In a perfect world, all 3 are the same. Far too often, when automating business processes, I'd run into the conflict. If you implement #1, on paper the project succeeds but it can't do what it is needed to do. If you implement #2, the mismanagers are happy, but it still can't do what it is needed to do. If you implement #3, the mismanagers won't pay because it doesn't meet the specs in their minds (nor the ones written down).
If you have good business analysts, you can/will discover the mismatch before too much time, sweat, money and development have been spent paving the wrong cow-paths.
most things are simple enough they just don't need workflows. Fetch -> Respond or Fail is good enough for most things.