Designing for Disability

Through learning how to code alongside a diverse group of people who learn best using a variety of methods, I myself have learned a very fundamental principle: different people with different skills and knowledge learn differently. This is similar with learning across all subjects and skills. While some people are visual learners, others are more attune to a more hands-on learning experience. It’s important that all designs for public use embrace the diversity of its users to change the design of their display to be more effective, since some designs will work better than others. When dealing with the internet and any public source, most things must be easily interpreted by the most number of people.

With that, we turn to the code writers and program design groups who study what makes the user interface easier to use. How do we develop and design websites and applications for those with cognitive differences? Not all effectively written code is considered “effective” by those with inattention, anxiety or depression disorders. Knowing that, how can we make our code better for those in the general population who are affected?

To research further, I used the blog post “Designing for Cognitive Differences” by Brandon Gregory, a software application designer and developer, as reference. He explains the common symptoms of common mental disorders such as inattention, anxiety, and depression. He then goes on to explain that the primary solution to such disorders is creating inclusive designs. This means that the user interface is improved to make sure that users who suffer from certain mental disorders are not swayed from using their application through simple things like changing a “submit” button to say “send payment information” or “change sound settings”. These are small improvements, but they make all the difference. Brandon Gregory then concludes his post, by explaining that,

“…  disability takes many forms, and accessibility and inclusive design need to take just as many. In our industry, compassionate discussion around physical disabilities has been a huge benefit, and cognitive differences need to be part of the conversation too. Removing unnecessary distractions, reassuring users that they’re doing the right thing, and keeping things easy for users who are struggling are things we can do to accommodate these users and make them feel like you actually want them to use our sites and apps. As one of these users myself, I can say we would really appreciate your efforts. ” -Brandon Gregory

As someone who knows many people with the listed disabilities, I enjoyed this article. It clearly identifies what people struggle with and how to improve every day websites in little ways to be better used by the general public. Being aware of these disabilities will make the internet more safe and easy to use overall.


Measuring Productivity

Having taken multiple team-based software development classes, I’ve always wondered how software development teams measure and record their productivity levels over the course of an entire project. Are there certain metrics to use in order to measure such productivity over time? Is this metric universal to all software development projects, or does it vary depending on the purpose of the software?

To research the answer a bit further,  I read “Measuring Developer Productivity” by experienced developer, Max Kanat-Alexander. In this blog post, he begins at the root of what productivity is; essentially, it is the making of a certain product, a process which can be deemed effective when it takes the least amount of time and materials to complete. He continues by explaining that,

The key to understanding what productivity is is realizing that it has to do with products. A person who is productive is a person who regularly and efficiently produces products. – Max Kanat-Alexander

This clarifies the definition of what productivity is and thus allows us to understand that productivity must be measured over an increment of time. A productive team is one that produces developed software that fits all of the necessary criteria in a time efficient manner. Now, do we count developer productivity in keyboard clicks? Lines of code? Neither. Kanat-Alexander outlines his point as he explains that,

The point here is that “computer programmer,” like “carpenter,” is a skill, not a job. You don’t measure the practice of a skill if you want to know how much a person is producing. You measure something about the product that that skill produces. – Max Kanat-Alexander

I found this point in particular to be incredibly interesting to consider. Instead of being measured by a very small and insignificant portion of the job, the metric necessary is project/job dependent. How many tasks of your job can you complete in a single day? In a single hour? If you are able to complete many small tasks, then you are very productive. Even if you are able to complete one very large task, then that is also considered productive. The way productivity should be measured is by the weight and size of the task and how many you are able to finish to an effective working level each day of development. With this metric, it is easier for managers to grasp how productive their software developers really are.

The Process of Reviewing Code

Since CS-343 is meant to teach us about how to craft and design better code, I figured it would be important to first identify the key components of reviewing code, whether it be your own or someone else’s. To do this, I used the article “Yet Another Code Review Best Practices” by Pawel Ochman as my main reference.

He begins by describing some of the reasons for reviewing the code, leading into a few tips and things to look for, ending into a note about how to maintain the code after your review. With all of this information, a few key things stuck out to me:

  • Prior to reviewing the code, you must create a goal. There can be a single or multiple goals, but no matter what all code reviewers must have common goal(s). Some examples of these goals include:
    • Eliminating bugs at an early stage
    • Improving code quality
    • Increasing knowledge about the project
    • Learning from each other
  • The most important principles to follow when reviewing code are quality and motivation. In this context, quality is the principle of making sure that every time you review code, you review it to the best of your ability. Similarly, motivation is the principle that plays as a constant reminder of the values of code review to keep the team/yourself feeling positive about the review/editing.
  • Positive feedback after reviewing the code is important for whoever’s code it is. The values of code review outweighs allowing it to continue to be inefficient or ineffective in functioning/solving the problem (whatever that may be).
  • The most important point is that you don’t have to be an expert:

It’s a great chance to learn something new. If you are not sure whether solution is correct, you can start a valuable discussion. As a team member you should be able to work on any area of the project. Don’t allow any person to be the only expert in specific part of an application. You should be able to replace anyone in case of his absence.

All in all, this was a great article to learn from as it allows you to see the benefits of  code review through each stage. With small pieces of advice, it transforms what may be a painful process into a more positive one.


Our Future Role

Before shifting into the details and techniques of how we, as developers, can design and improve software for the future, I felt as though it would be better to start off with a more general post about where software is taking us.

As people in this particular technological age, we depend on software to be effective every minute of every day of our lives. In this way, we are spoiled. With new advances in technology being released rapidly, we have almost become accustomed to having so much technical capability right in our back pockets. With this, we have begun to catalog and store everything about ourselves, since the amount of data storage we have is at a relatively infinite capacity. With such capabilities at the touch of our fingers, is it our jobs, as future software developers, to protect the general public against the possible repercussions? Are there evils afoot that come with such good?

To find out more information (and a few answers to these daunting questions), you may turn to non-other than Jeff Atwood, a software developer, who created the blog post “To Serve Man, with Software” on his blog, Coding Horror. He begins by describing the role of programmers today, beginning all the way from the early decades of coding, in the sense that programmers have always been the ones ruling the world. This, at first, seemed like a good thing. Programmers and software developers could change the world and do all sorts of good with their powers! However, is it always good?

What do you do when you wake up one day and software has kind of eaten the world, and it is no longer clear if software is in fact an unambiguously good thing, like we thought, like everyone told us … like we wanted it to be?

This should be a reminder to each of us how powerful software is, especially in our world today. Ensuring that all of the software that is being developed has a morally and ethically right purpose and that it is so specified that it cannot be used for anything other than it’s original intent is gravely important. As software developers, this is a critical concept to keep in mind.