I read an article today titled, “I Know What the Apple Vision Pro Is For” in the New York Magazine. It was very interesting seeing how the Apple Vision Pro (AVP) is making a difference in the lives of people with disabilities. I find it amazing that Apple was able to make the device so accessible but see why they were able to be successful. They still have some work to do as the article points out but they have done a great job with the device.
Apple was able to be successful because they have developers on the team, who themselves have disabilities. This provides a few advantages for producing something that is accessible. First off, the developers have first hand knowledge of what will work and what will not. It is like having the business owner writing code or making design choices. Secondly is developers, who do not have disabilities can get near instant feedback.
I have not had the opportunity to work with someone who has a disability. I have worked with one individual many years ago, who I believe had oculocutaneous albinism, just as Maxine Collard, in the story. I recall that they had a jewelers loop and would get right up to the Cathode Ray Tube (CRT) monitor to see the screen. I guess that made the article a bit more special to me as I saw their struggles first hand and can imagine Maxine Collard’s interactions with the computer and other challenges she faces.
Getting near instant feedback is important to writing better code and really for doing anything well. I recall the first time that I worked on a project where the development team needed to write unit tests for the code that we were writing and coupled with DevOps and automated testing. It was a powerful combination. I was able to check in code and tell within a few minutes if the code was going to break the build or not. It was great when the code did not break the build but when it did, it was great to know it right away so the code was still fresh in my head. I did not need to get back into the mindset that I was in a week or two ago. Getting back in the mindset and remembering what you were doing when you wrote the code, why you made the design choices you did takes away valuable time that could be used to code the next chunk of functionality. I was so impressed by the time saving and the empowerment that near instant feedback gave me. I built a small device to show me the status of the builds.
The near instant feedback gave some additional benefit to the project team as well. It did not eliminate defects, but it did result in fewer easy to find bugs. I did increase development time but the added benefits I feel outweighed the additional development effort and given enough time, would actually reduce development time as the developers would improve over time.
The immediate benefits is the code would be more robust, particularly around data input validation and business rule checks. Testers can write code to test these things but it takes a great deal of time to test various combinations of data inputs, edge cases, and requested business rule behaviors. Unit tests and the execution of those tests when a developer checks in code catches most of the issues that can arise from these cases.
Additionally as I started getting use to the instant feedback, I found that I was checking in code more frequently and was more comfortable in breaking code and user stories into smaller pieces. The reason for this I believe is two fold. Firstly there is gratification in seeing that code is checked in and passes tests as it is working as expected. Secondly, there is greater confidence that I change something that may impact some other functionality as I can be somewhat confident that if the code will break anything else, I will know it once the code is checked in.
While the article was on accessibility, I think there were some other things to learn as well. Getting near instant feedback is a great path to creating something that is reliable and works as intended. You can still develop code that no one uses, but it will be quality code. If you want code that users will find is useful, you need to get usability feedback as soon as possible from the community that will be using the software. Apple is a great example by including people with disabilities on their development teams.
