It strikes me that a problem with this analysis is with the modeled example system itself. The assumption that stock should follow immediately preceding demand is valid but typically wrong.
Pursuing the intellectual mechanics of a system is obscuring the error of the wrong system!
Instead stock levels should take into account lead time, historical seasonal demand, and a subjective value. The observation and order frequency should be in months not days.
While computing allows near “real time” everything, that doesn’t mean it should necessarily be applied.
Just-in-time thinking needs to take the reality of the system (in this case the supply chain) and other factors like hedging opportunities?
It strikes me that a problem with this analysis is with the modeled system itself. The assumption that stock should follow immediately preceding demand is valid but typically wrong. Pursuing the mechanics of a system is obscuring the error of the wrong system!
Instead stock levels should take into account lead time, historical seasonal demand, and a subjective value. The observation and order frequency should be in months not days.
While computing allows near “real time” everything, that doesn’t mean it should necessarily be applied. Just-in-time thinking needs to take the reality of the system (in this case the supply chain) and other factors like hedging opportunities?
Lines of code, functions and modules, are insufficient for producing quality representational systems i.e. those that model external systems. There is a lack of sufficient abstractions.
Unlike transformational software that can use mathematics as a conceptual framework, representational systems have no such thing.
Yet it is complex representational systems that allow the operation of our modern world.
Human coding effort without such a framework is problematic, and that is just exacerbated with AI generated code. Should we be surprised that for this type of software AI makes thing worse?
Quality software meets its requirements. Both functional and non-functional. Of course our industry still cannot quantify non-functional requirements, or discover a way to predictably implement functional requirements.
So all that remains for our so called “engineering” discipline, is an answer that says something that doesn't break a lot.
All I see is disgusting popups - “k-ll j——“, “r-pe n——“ Very upsetting, no thanks to you.
Who wants that on their web site? In some jurisdictions you’re going to be in trouble for facilitating hate and calls for violence (or worse). This is why what you have implemented will not work in its current form. I suggest you move to a system that characters can trigger only standard phrases and emoticons.
Frankly I’m sad to hear it. There are just too many programmers - simple.
30 years ago or so, I was a contractor working on back-to-back 3 to 12 month C++ projects. I would typically get a call one day from a recruiter followed by a phone call (or maybe a quick meet or coffee) with someone technical on the project, and arrive and be in the codebase the next. That day I would get 2 calls about my availability.
There was no sh*t-show of continuous deployment, code reviews (even for trusted internal projects), and scrum-like ceremonies. There was instead version control, periodic tested releases, a weekly update meeting, a Friday team lunch at the pub, and trust.
Too many programmers (sorry err Engineers) - too few jobs, and the enshitification of an industry.
What concerns me the most is that improvements in software design are at an end. The “big ball of mud”, which really is a problem of modularity and dependencies, will never improve through innovation because the way it is done now is all there will ever be.
Email them because most people these days never receive a personal email from another real human being, instead of newsletters, solicitations, marketing, announcements, notifications and spam.
hn638 [at] aryeh [dot] sent [dot] com