On 02/07/2025 18:06, Dawn Wolthuis wrote:
> If so, I’m happy to be wrong about this. It is likely the case that only 
> those who have previously worked with MV would think of putting it in 
> their stack for new software, but if it is cost effective for new, 
> contemporary apps to use MV, then that would good to know.
I'm struggling to get OpenQM into my company as a new stack component. 
There's no opposition to it especially, just big company bureaucracy. I 
did try ScarletDME, but the company is less and less inclined to use 
Free Software. It's gutting - if I'd tried a year earlier I would 
probably have got away with it ...
You'll know who I work for from LinkedIn - and I've got back into my 
preferred role which is a programmer with a completely unrelated job 
title! :-) working in a very-much-end-user role.
Our current software stack is mostly a massive data lake, which we're 
drowning in with no information. And the system I'm working on is just a 
morass of Excel spreadsheets, with loads of BigQuery data feeds, none of 
which (I might be exaggerating - SLIGHTLY) with any primary keys.
As a result we have multiple sources of truth, a variety of different 
ways of calculating the same derived data, missing links that stop us 
pulling things together ...
My job is to take all the dollies of shopping coming out of the 
warehouse/picking sites, putting them on lorries, and getting them to 
the distribution centres where they go on vans for final deliveries. Our 
new all-singing all-dancing system couldn't tell us which van routes 
were being picked in which warehouses! And our botch/workaround was to 
find routes that had shopping (which told us the warehouse), and apply 
it to similar routes. This worked well until ... they introduced "same 
day" routes, which only got shopping on delivery day ... seeing as we 
need to know at least a week in advance, we were up a gum tree, which is 
our usual position at the moment :-(
Which is why I want a simple, easily understandable system like QM, into 
which I can slurp all this data, and where I can make the system scream 
blue murder if it's missing necessary data.
I'm sure, once I've got the system working, they're going to try and 
slurp it into our new all-singing all-dancing system, but I'm going to 
be sure to point out (repeatedly) "how can I - as a one-man crap 
programmer - design and build a system in six months that they're 
planning a multi-man-year project to replace?"
Our fancy new system "was two years away for five years". I take great 
pleasure now if I get the opportunity, pointing out that MV has the 
reputation of delivering before time and under budget. My only problem 
is that if I get given the chance, I've GOT to deliver. Okay, retirement 
may only be a few years away, but I have no intention whatsoever of 
cutting and running ... :-)
And given that we're a week away from shutting down our old system, I 
might very soon be called upon to deliver! Yay! At least I've already 
earned in this new job, my typical reputation in previous jobs of 
identifying and implementing automation that speeds things up massively. 
A macro that got me the compliment "You've turned a two-day job for an 
experienced analyst into a half-day job for a rookie helper". Or "you've 
reduced this on-call job (ie under a lot of time pressure) to one third 
of it's previous time". I'll be pushing that, for sure ... even if I'm 
just picking off low-hanging fruit - there's just so much of it!
Cheers,
Wol