I don't get it. How is this different than starting new threads?
In the article example, it doesn't look like anything is returned from each parallel function call. the main loop just invokes the func for each I, and they print when done. No shared memory, no scheduling or ordering.. what's the advantage here?
In code examples, seems shared memory & scheduling are not a thing either. More like functional or chain programming - a function calls next func and passes output to it. Each loop runs independently, asynchronously from others.
Reminds me of ECS model in gamedev.
That's great and all, but it doesn't solve or simplify intricacies of parallel programming so much as it circumnavigates them, right?
Is the advantage it being low-level and small?
I think the same "concept" can be done in Bash:
```for i in $(seq 1 100); do fizzbuzz $i & ; done```
Now I want to be devils advocate and give you the "corporate" perspective -
You say Agile disrupts your "flow", makes you deliver buggy code and just work to close tickets like a drone?
Good!
Who said code needs to be perfect and bug-free? remember Lean? Just get it out there! we can always fix things later.
From a business perspective - we are spending money to develop functionality, not our peoples skills.
Tickets and tasks should result in adding value to the business, not to our codebase.
This is a cruel and unsustainable way of thinking, which will have your best developers leaving the company very quickly. But if you're an enterprise corp - you see them as interchangable "resources" anyway, and Agile helps you accomodate to them leaving by splitting the work to small bits and having no single owner.
It's a good way to set expectations for what will be/is to be delivered in a Sprint, and limits going off-piste in too many directions while not delivering functionality (which is a problem for creative/broad-skillset developers at times).
It also limits the impact/waste in case the requirements change - you only worked two weeks in the wrong direction. (and they say changing requirements is the biggest problem in software projects since ever)
However, I find that it often reduces developers to mindless drones, just trying to satisfy acceptance criteria without thinking about the big picture. (You know you're there when Refinement meetings are very quiet and the Architect does most of the talking).
As for estimation/scoring - I find that estimating "complexity" is nonsense. Treating points as "days" is more realistic and leads to better time management from everyone.
A little disappointing actually! I thought the pattern was a clever way to capture the status of the parachute in the event of failure, so if all they got was a garbled low-res image before the lander crashed to the surface they could deduce which section failed. Alas, it was just an easter-egg..
Thanks! I mentioned Synergy as I've used it many years ago and was not aware of license change implications (that's why I linked to the open-source repo).
Good to know there's a good fork.