Not only is the shop in business, it's one of the most profitable place I've had the pleasure of working at. The policy was actually handed down by the CTO, who started in the company as an entry level developer. Some money was incidentally saved, but, at least to hear him talk about it, it was more about getting people's incentive structures in line: If you want to discourage developers from doing something, the most straightforward way is to make it painful for them to do it. If you want to make creating performance problems painful, you accomplish that much more effectively by making it apparent on their workstations, where their nose will be rubbed in it constantly until they do something about it. Slow performance on an external test environment is much easier to ignore, because people typically don't bother testing there until they think they're basically done with their work, at which point their incentive structures are nudging them toward ignoring any potential problems.

Contrary to some of the criticism I'm seeing here, it wasn't actually hated by the development team, either. The hypothetical "can't get any work done because compiling takes a bazillionty days" scenarios that people are pulling out of thin air here simply didn't happen. At a shop where developers were expected to think carefully about performance and know how to achieve it, they tended to do exactly that.

Someone who was busy making excuses about how they weren't very productive because they only got a 3.4 GHz CPU while the analysts got a 3.6 GHz CPU probably wouldn't have lasted long there.

> At a shop where developers were expected to think carefully about performance and know how to achieve it, they tended to do exactly that.

As long as you have time to actually achieve this, remove that and even on the worst hardware, you'll see shitty implementation.

"Yoda talk" is a very nice phrase, I hope it catches on.

Dogfooding is sometimes a good idea, and of course testing on a range of setups is important. I suspect there is a problem with people testing on older software but not trying any older hardware (especially for web apps), which using old machines could have partially avoided.

But the idea that development should inherently be able to happen on older hardware than the product will run on is arbitrary and ridiculous. At best, that creates pointless pressure to rely on hardware-friendly tools, which could mean anything from not leaving open lots of relevant Chrome tabs to pushing developers to use vim instead of a Jetbrains IDE. (Nothing wrong with vim, obviously, but "we intentionally hobbled our hardware" is a weird reason to choose an environment.)

At worst, it fundamentally impedes development work. For an extreme case: Xcode isn't really optional for iOs development, and merely opening it seriously taxes brand new Macbooks - applying this theory to iOs developers might leave them basically unable to work. Even outside that special case, there are still plenty of computer-intensive development tasks that are way outside user experience. Just from personal experience: emulating a mobile phone, running a local test server for code that will eventually land on AWS, running a fuzzer or even a static analysis tool.

Even if we grant the merit of that trite "remember who you work for" line, sticking to old hardware doesn't seem to follow at all. We wouldn't go around telling graphic designers that if they work for a customer with an old iMac G3, they're not allowed to have a computer that can run Photoshop. Heck, are there any professions where we assume that building a thing should be done exclusively via the same tools the customer will employ once it's finished?

My company’s mobile app is made in react native.

As a senior dev., I still use an iPhone SE, but the mobile dev team all have the latest iPhones.

The app looks horrible on the SE, and some touch areas are blocked by overlapping text or images.

It is basically unusable on a supported device.

I worked in a place where dev workstations were far beyond the end users', and when devs tested (mostly local, not multiple systems across networks), there was no basis in the customers' reality.

Endless performance problems were masked in development, and then very noisily evident when it reached customers. Performance testing was largely reactive and far removed from the creators of some terrible code choices, so they'd tend to shrug ("Works fine here") until you analyzed the hell out of it.

Now, the code was a big C++ environment, and compilation speed was a problem, but maybe a means of testing in a throttled state would have prevented a lot of grief much, much earlier.