The key insight here is the same reason why every internal department service eventually goes to a ticket system - adding queues (and by extension delays) improves efficiency. Resources can be used at 100% capacity ('always more work to do'), you can offer good service to only those who matter (i.e exec VIPs), and you can batch work (pour 2+ cups of brewed coffee at once).
Unfortunately it means that any time you need anything from someone outside your team, it comes with a lead time of '3-5 business days' unless you know the magic words or you raise it up the chain.
One of the big design challenges with self-driving cars like Waymo is communication with pedestrians - have to have some analogue to making eye contact or waving so pedestrians know they've been seen (possibly through audio or LED message signs)[0]
It's fascinating to me that a plane in full (emergency) autonomous mode, having run an algorithm to identify airport and landing sequence, is using speech to text to broadcast over analogue radio to the humans in the area. And the tower tentatively communicating back ('Outfitter 9, if you can hear me, cleared to land...') to do the expected final step in the exchange.
Have you tried going through Sales? Account teams can usually move mountains if they can see a clear path to a paycheque - you might have luck just by going to the 'chat with me' popup on the azure home page and saying you have thousands of budget and would like to chat with a rep.
I attempted to say I needed to speak to a sales representative. The AI ran me through the standard question gauntlet.
I closed the browser entirely, reopened it, and then told the AI that I "have a large budget and need to speak to a sales assistant". It then asked one question: "Is this for a business or personal purchase?" I said business, and then boom, immediate connection to a human.
THEY were able to submit the support ticket for me. But their recommendation? Just create a new account entirely. Which, obviously, is NOT an answer.
When your ONLY source of "help" is the only people in the company you can reach telling you to just "give up" on your primary account, I think it's time to switch vendors.
Salespeople are often non-tech despite working for tech-firms, non-tech people are the ones who usually create messes by workarounds since they often quickly give up instead of reporting.
If the non-reporting is a problem of the non-techs or techs at a company is an open question, but it's often a shared problem connected to non-techs coming with stupid things at one point and fundamentally important stuff at other times.
Anyhow, they usually should know how to get proper escalation to get shit done when hounded enough.
I let them know that if this isn't solved by COB tomorrow, I'll be pushing the client to switch to a new vendor. Then I received the email for the support ticket and see that they set it at the lowest priority.
I've already started playing with AWS to see how hard it is to spin up VMs there.
There's also digital ocean and hertzner cloud if you don't want to enter the AWS money pit. Though if you're looking to become a forensic accountant, AWS billing is great training
So to fully close the loop, I convinced the client to go to AWS after this week's debacle. I showed them how simple it was to spin up a new box on AWS, and everything just worked. Then, I showed them how DIRECTLY within the AI help interface, as SOON as you say you "need to speak to a human" it gives you the SUPPORT TICKET INTERFACE to fill out RIGHT there. No "you must have a support contract to ask about a billing question" horseshit. DIRECT access to the support ticket system.
The customer has agreed that we should pivot to AWS. Microsoft has officially lost a $10M, 10 year contract, and it's going to their primary competitor.
I wonder how often this really happens, just so they can save a few bucks on tech support?
In my experience, having a fixit week on the calendar encourages teams to just defer what otherwise could be done relatively easily at first report. ("ah we'll get to it in fixit week"). Sometimes it's a PM justifying putting their feature ahead of product quality, other times it's because a dev thinks they're lining up work for an anticipated new hire's onboarding. It's even hinted at in the article ('All year round, we encourage everyone to tag bugs as “good fixit candidates” as they encounter them.')
My preferred approach is to explicitly plan in 'keep the lights on' capacity into the quarter/sprint/etc in much the same way that oncall/incident handling is budgeted for. With the right guidelines, it gives the air cover for an engineer to justify spending the time to fix it right away and builds a culture of constantly making small tweaks.
That said, I totally resonate with the culture aspect - I think I'd just expand the scope of the week-long event to include enhancements and POCs like a quasi hackathon
I've come to appreciate that using AI tools are a skill on it's own. Anything beyond auto code completion takes quite a bit of conscious effort to experiment with and then learn how to delegate to in a workflow. They often end up being valuable, but it did take some work to get out of my productivity 'local maximum' that maybe not everyone would naturally take on.
I like thinking about the ISS as primarily engineering (and operational) experiments rather than hard science. As a space platform, it's provided learning on how to contract private companies for space flights, and in turn, how they should operate, plan, etc. Or how to do internationally coordinated space operations. All of the work it takes to mature a new tech to a 7,8, or 9 on the NASA Technology Readiness Level[0] while Curiosity and Ingenuity and other long-distance (and JPL) missions focus on the hard science of 1's and 2's.
That said, I too think the main value of ISS declined several years ago or more. Looking forward to the next generation, whatever it is
> As a space platform, it's provided learning on how to contract private companies for space flights, and in turn, how they should operate, plan, etc.
This would be great if we knew where we are heading. Without a clear goal/destination the most likely outcome is we get board and lose the institutional knowledge we paid so much money to gain.
I get the sense that #2 is viewed as a risk for DRM, given all the work that goes into preventing firmware downgrades to potentially insecure firmware. Specifically thinking of the Nintendo Switch[1] that goes so far as to blow fuses on each firmware upgrade!
eFuses were already on the Xbox 360/PS3 generation. Smartphones also use them to lock out proprietary photography algorithms if you unlock the bootloader.
You piqued my interest enough to go hunting - this StackExchange[1] question estimates ~19% of fuel is spent on initial climb-out to 30k feet for a 737-800 on a 5-hour LA->JFK flight.
Without doing hard calculations, it intuitively feels pretty marginal potential flight weight savings for the operational complexity it would add
Worth noting that EV aircraft flight segments are likely far shorter (100--500 km, maybe at a stretch 1,000 km, not the ~5,000 km of JFK->LAX), and cruise much slower (~100--300 knots, say), so climb-out would be a proportionately larger share of the energy budget.
And ditching 20% of your energy storage mass immediately on attaining altitude would still be a considerable savings for the remainder of the flight as that mass doesn't need to be kept aloft.
EV aviation (and aviation itself) is a battle of thin percentages. EV aviation itself has relied strongly on materials advances (advanced fibre composites), and reducing crew (ultimately: autonomous piloting). The need for cabin crew for safety reasons remains, and would be a significant hurdle. The extent to which non-revenue occupants and payload can be minimised likely plays a huge role in any eventual success. A 19% reduction is nothing to be sneezed at, if it can be achieved without significant other compromise.
Any extra time spent during a burn is wasted fuel. Intuitively, any time before the rocket is in orbit, some part of the rocket thrust is resisting the force of gravity or else it would fall back down to earth. The longer that time is, the more thrust (and thus fuel) was spent negating that force. It's the main reason why the Falcon 9 boosters do a 'hoverslam' on return and land at close to full throttle - any extra time during that burn is less fuel efficient.
Better fuel efficiency = more payload to orbit = plenty of justification for the extra complexity.
Admittedly gravity losses are more significant at the beginning when the booster/ship are ascending purely vertically than later in second stage flight which is mostly horizontal, but definitely still a factor.
Also from a license negotiation perspective, gives the buying company the option to threaten to self-host and/or fork. Even if they never do (and I'm sure the source company is very careful to balance the value story), it can act as a ceiling for rate increases or other annoying business practices.
Why would a company ever open-source their product then? Giving up that complete leverage can be a selling point during the purchasing process, making buyers more comfortable that they won't be (completely) locked in, and be a net positive on revenue through faster sales.
Unfortunately it means that any time you need anything from someone outside your team, it comes with a lead time of '3-5 business days' unless you know the magic words or you raise it up the chain.