Comment by saagarjha | Hacker News Reader

Comment by saagarjha | Hacker News Reader

Parent Full thread

I think that's part of the argument for this, yes–a company that doesn't provide their developers with the best tooling is hurting themselves because they're wasting their developer's time. But I'll argue that the opposite can be true as well! By using a machine that is far removed from what your customers are on, can you really test their user experience?

And, this is a personal anecdote of course, but sometimes having fast machines can paper over problems that you should really be addressing: I had a coworker once who temporarily used a fairly (~7 years) old machine to do their development work until they could get something newer to work on. During that time I noticed that they would take a while to make minor fixes after reviews. I asked them why and they told me that they would make the change and then they'd build it and it was taking dozens of minutes–it turns out that there was a creeping dependency tracking issue in the build process that nobody had bothered to address yet because it didn't seem like a huge issue on our normal machines. But fixing it certainly got his turnaround time way up, and the CI machines really liked the change too ;)

Why would a developer be in charge of testing the user experience from the user perspective? Either have good relations with your end users or use QA with properly outfit machines.

Or you should -know- what specs your users are using (this is really not hard) and optimize for that.

You can get chrome to degrade network performance etc. It's not easy to downgrade machine performance tho.

> Why would a developer be in charge of testing the user experience from the user perspective?

I can count on one hand the number of companies I've worked at in the last decade who had in-house QA teams. Most companies just rely on the developers to test their (our) own code. The exceptions are banks, gamedev companies and big corp products (like Windows).

Most web software I've seen - especially in the startup world - just assumes that "it works well enough on the developers' specced out mac" means it works. The most tragic version of this I saw was our app looking awful on a ‘normal’ 19” desktop monitor. The problem was our designers did all their work from 27" imacs. They never thought to design and test on smaller displays. Or the designers placing adjacent colors that look great on color graded displays but are almost indistinguishable on the trashy 6 bit TN displays that were ubiquitous in offices a few years ago.

Even in companies with dedicated QA I haven't seen many tickets of the form of "the program runs slowly on this old computer we have". Sadly the creeping performance rot is mostly invisible.

I worked at an education tech startup so we were mildly aware of our app being run on slowly performing computers. Low bandwith conditions were more of the worry tho.

Honestly, people running slow computers are probably just used to poor performance. I fully agree with you that we should do something about it but I don't see that happening unless it's a strong priority (feature X/y/z or performance? is usually the conversation).

Anecdotally: I'll never forget the first time I launched an app from an SSD and vowed I was never going back.

You can simulate a slower machine with a VM, or by disabling extra cores and memory on your dev machine, or by running your app off a slow external drive.

It's not as easy to do this as it could be, but it's not that hard either.

Why would a developer be in charge of testing the user experience from the user perspective? Either have good relations with your end users or use QA with properly outfit machines.

It doesn’t have to be either/or, it can be both. Developers absolutely should be using their own software frequently, seeing and feeling how well it performs; trying it out on a lower-spec machine is always a useful exercise.

That doesn’t mean you can’t also have dedicated QA. Developers shouldn’t have to be in charge of QA, but they should have some involvement.

Simply run your app in a VM, that should degrade performance, customizable as well.

I'm not really buying that. You can limit ram access but even at a single core i7 you're going to have better JS performance than some i3 from 10 years ago.

Hypervisor / virtualization tech should mean you get very close to actual host OS performance. Otherwise this whole container thing wouldn't work so hot?

> It's not easy to downgrade machine performance tho.

  yes > /dev/null &

Repeat until slow ;)

Reply on news.ycombinator.com