There is some merit in what you are saying, but it only makes sense to a point. For example, should you dev without any screen -- instead relying on a screen reader -- to make sure that you produce accessible apps? Assuming you do that, how are you going to know if the app looks as you intended when someone does have a monitor?
Or if you produce code on low-powered devices, how do you know if it will scale up in capability with higher powered devices? (Or that it will even work anymore?)
Rather than focusing on constraining your dev machine artificially, it's probably better to test the end product on the environments (along with their constraints) you are targeting.
You are right to the some extent. And I can think about many other examples and counterexamples. But it all depends on what you as a developer really want. If you want to make really accessible application, especially targeted for a blind people and want to make it in a best possible way, you definitely should have an visually impaired programmer in the team.
You may have great QA team that to test the program and claim it is slow, but if the developers think (subconsciously) that the program is fast enough, it will never be fixed. The development speed will slow down and the developers will find a way to persuade all around that it is impossible to make this program faster. The release date will come and the program will be released slow.
So, if you can suggest the developers that the program is slow in a way they really believe it (not simply to agree) they will make it faster. If not, well, the next slow program will be released.
There is some merit in what you are saying, but it only makes sense to a point. For example, should you dev without any screen -- instead relying on a screen reader -- to make sure that you produce accessible apps? Assuming you do that, how are you going to know if the app looks as you intended when someone does have a monitor?
Or if you produce code on low-powered devices, how do you know if it will scale up in capability with higher powered devices? (Or that it will even work anymore?)
Rather than focusing on constraining your dev machine artificially, it's probably better to test the end product on the environments (along with their constraints) you are targeting.
You are right to the some extent. And I can think about many other examples and counterexamples. But it all depends on what you as a developer really want. If you want to make really accessible application, especially targeted for a blind people and want to make it in a best possible way, you definitely should have an visually impaired programmer in the team.
You may have great QA team that to test the program and claim it is slow, but if the developers think (subconsciously) that the program is fast enough, it will never be fixed. The development speed will slow down and the developers will find a way to persuade all around that it is impossible to make this program faster. The release date will come and the program will be released slow.
So, if you can suggest the developers that the program is slow in a way they really believe it (not simply to agree) they will make it faster. If not, well, the next slow program will be released.
Seems like there is a bigger problem with the organization if no one will listen. Low powered dev machines won't help that.
Oh, they will listen carefully. And they will agree. But only in words.