Amusingly, I was warned away from using Petri nets as the execution model for a workflow manager because "you can't prove the net will ever complete". Since then I've used several large-scale petri net-based workflow engines that ran large-scale industrial computing projects without problems, so I think that complaint was excessively theoretical.
That is funny, appreciate the anecdote. I have encountered resistance to application of lesser known ideas in daily practice in my life, because even as engineers, sometimes there is the fear that we are veering off into esoteric-land. Especially in a corporate setting, getting the balance between true engineering and the science involved and "go fast and break things" is tough.
I have always felt that the key to being an engineer is to understand that theory is a tool, and what makes it fact is science (wow, cool science! LOL) - testing the theory by putting it into practice and measuring the result/iterating. The fact that Petri nets give you a way to talk about the proof as well as model the problem is part of what makes them interesting to me.
So I guess I'm saying, moving fast while applying science.. and the learning and iterating.. that just makes sense right??? If the result is a working system, even better! Science and being agile are totally compatible!
The burden of proof is on everyone, to say, OK.. I am following this technique because it helped me build a working system. I am standing on the shoulders of giants, and the system has been tested and works... but if you don't think the theory is correct, then please, prove it wrong. Make it better, improve, iterate!
In this case, with a genuine and positive attitude, I kindly turn the computer keyboard around to the other person and ask them if they know a better way, to please explain it and I'm happy to learn and adapt. I'll show my proof if you show me yours, and we can discuss, kind of thing.
