Sometimes that requires expertise in a very low-level topics. For example I've read a similar story, but developer digged the truth. Production was running on vmware cluster with live migration or something like that. Servers used slightly different CPUs (frequency differed a bit), so VMware emulated some important instruction (something related to get current timestamp). MSSQL used that instruction a lot in one specific scenario, so it was running much slower on virtualized production server.

They were able to figure it out and rewrote one stored procedure so it ran fast again. But I'm sure that I, for example, don't possess the necessary expertise to figure this out. I wouldn't be surprised that in many small-to-medium companies there are no experts of that level either.

Time Stamp Counter (TSC) has been trapped to make sure it returns the same value across all cores. Intel fixed that part, though.

In a live migration scenario the TSC in the source and destination machines will be necessarily different so that emulation is required to make it not warp.

That said, due to previous TSC instability all operating systems deal with a TSC warp pretty well. Whether applications deal well with it is probably the reason why emulation is the default, but it could be that this can be disabled.

(Everything AFAIRC)

Sure, across all cores on a physical CPU socket. But not across CPU sockets.

Probably VMware fault tolerance which keeps a virtual machine in sync over 2 physical machines to allow instant failover. But I can imagine that taking a lot of instruction trapping.

I would never get the CPU instruction bit but I'd like to think I'd get as far as the stored proceedure.

Ship first, dig self out of absurdity later.

Later being codeword for never

Maybe the horse will learn to sing? https://en.wikibooks.org/wiki/Sufism/Nasrudin#Nasreddin_and_...

Maybe putting the laptop in the data center lets you do the launch. Maybe the launch is a flop because you forgot to advertise it. Maybe you raise series A funding; maybe you don't and the site dies in three months, still happily running on the laptop. Maybe someone decides to re-write the product in a different stack. Maybe the product was wrong and needs to pivot.

A lot of products have shipped and succeeded with absurd hacks in them. Hex-editing the binary to change "EMM386 Memory Error.." to "Thank you for playing Wing Commander", etc.

I believe the correct translation is "in the fullness of time as we address technical debt."

I know that I'm a small sample size - but in my career so far, "later" means "never" a lot more often than it actually means "later". Especially when it comes to paying down technical debt.

In my similarly limited experience, this is directly correlated with equal parts 1) how strong-willed the architects and technical leadership is; 2) how [dis]functional your non-technical leadership is.

Most good developers want to pay down technical debt. Most good architects are able to balance business and technical needs enough to know when and how to pay down what debt without spending four sprints renaming variables. It's when you have either dis-functional leadership who refuses to listen to their employees (most likely IME), or architects weak in either skill or constitution who can't or won't stand up the bosses to try to explain to them why we need to spend some time renaming variables.

I doubt it was a solution anyone liked.

Especially Bob

Bob probably got a newer-model replacement and was fine with that.

They probably made Bob develop on the server..

..until he gets matched performance.

If you hire only people with a superficial knowledge of things (the usual for the "big consultancies") that's what you'll end up with.

Isn't this worth some contest ? 1000$ to whoever figures it out.