In his post “The Psychology of Design”, Blogger Jon Yablonski writing for the blog “A List Apart”, discusses the importance of software developers to understand some principles about heuristic psychology that are helpful in improving user experiences and overall design.

Yablonski begins by explaining the concept of Hick’s law, the notion that the amount of time it takes a user to respond to a situation depends on the volume of information the person is presented with. He uses the example of a television remote, and how as the number and complexity of devises increases, the more confusing the remote controls become. But by abstracting the features to those only absolutely necessary, we’re able to create a much more user friendly product, as demonstrated by the apple TV remotes.

The author also goes into the idea of Miller’s law, which is the assumption that people can commit to memory seven plus or minus two different objects. Yablonski goes into strategies designers have used to work around this inconvenience; namely chunking. Chunking is used to break up large or complicated amount of information into chunks, like the digits in a phone number, or breaking up a news page in discrete parts.

Finally, Yablonski explains Jakob’s law, that people tend to form their expectations based on previous models that we have learned. For example, most video game controllers tend to have a similar arrangements of inputs. This serves to lower the learning curve required in adopting a newer model.

Personally I think heuristic psychology is very useful in the area of software development. Understanding how our minds process information is an integral source of data to help us achieve our goals of creating efficient, user friendly software. By applying smart strategies like design patterns to help implementation, combined by the insight of psychology, we should be able to handle a broad range of situations and have a good array of tools to help solve the problem.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

GivenWhenThen

Blogger Martin Fowler in his self titled blog describes a template for organizing unit tests, called “Given, When, Then”. This concept is perhaps a rephrasing of what we discussed in class, the four phase test, or “Setup, Exercise, Verify, (teardown)”. The idea is to structure our test cases in a logical, easy to understand process.

Fowler describes the idea as “essential to breaking down writing a scenario (or test) into three sections”. Given a specification, any situation we need to test for can be broken down into these three steps. The first section is “given”, or the “setup”. During this phase of the test, we would create variables and set up the preconditions to a test. Fowler uses a scenario of trading stock to illustrate his point. “Given” a certain amount of stock to invest (precondition) move on to the next phase.

The next step in the model is the “when” phase. During this phase of testing, we are choosing the behavior of a function to be tested. In Fowler’s stock trading example, this translates to “Given: x amount of stock to sell- When: I want to sell y stock”.  This phase essentially defines the behavior of the test we are writing.

Last but not least, the “then” phase is all about putting the first two cases together and verifying them. Following Fowler’s stock example, the “then” phase is represented as “Given: x amount of stock to sell – When: I want to sell y stock – Then: I should have x-y stock”. This phase is where you verify the expected behavior to the actual behavior of the program.

Personally I find this model particularly helpful, in the sense that it provides a useful narrative for breaking down testing situations. To me the “given-when-then” model seems more intuitive than “arrange, act, assert” or “Setup, exercise, verify”. While all three models definitely describe the same process, I think that this model is the most clear. In any case, breaking down test scenarios into discrete parts like this is integral to creating clear, easy to understand tests.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

Using the Simple Factory design pattern is a lot like making cheesecake

Software developer Sihui Huang, writing for the blog freeCodeCamp, explains the simple factory design pattern in terms that most people can appreciate – cheesecake.

Huang walks us through the basic steps in a simple factory for creating cheesecake. Starting with a number of his favorite types, he creates a makeCheeseCake() method which calls cheesecake.makeCrust, cheesecake.AddLayers, etc. The makeCheeseCake() method uses the type of cheesecake as a parameter, and calls the the steps to creating a cheesecake that all different types have in common. No matter what kind of cheesecake you are making, you still need to make the crust. So the makeCheeseCake() method is only concerned about the steps required in making any kind of cheesecake, it doesn’t care about what flavor the particular instance is. Huang describes this concept, as we have in class, as encapsulating what varies.

So Huang goes on to create a cheesecake factory class that handles all the different classes of cheesecake we can possibly create, and returns the appropriate cheesecake type by a createCheeseCake() method inside the factory class. The trick is that when you call the makeCheeseCake(), a new cheeseCakeFactory object is created, and uses the createCheeseCake method to determine what type the cheesecake is. So now the MakeCheeseCake() method does not need to know at all about what kind of cheesecake it is creating.

By separating the parts of a program that stay the same from those that vary, we can simplify adding and modifying different types of an object (in this case cheesecake) by adding a new class and adding to the cheeseCakeFactory class. No code has to be rewritten to accommodate for changes and removals of types of cheesecake.

Personally I enjoy Huang’s analogy to elaborate on the simple factory design pattern. Being able to separate varying parts of a program from parts that never change makes our code more understandable, coherent, and easy to modify. And the idea that a “factory” can handle the details of initializing different types of objects instead of having separate implementations for every object type is good design, and I think the cheesecake factory example is a good metaphor for encapsulation

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

“Coding with Clarity”

Software developer Brandon Gregory’s two-part post in the blog “A List Apart”, describes key concepts every software designer should follow in order to make the functions in our programs not only functional, but also efficient and professionally designed.

The first piece of advice Gregory shares with us is to maintain what he calls the “single responsibility principle”. In other words, each function should only focus on one process. By following this rule, we not only limit the margin of error in our code, but also increase the flexibility of them. Having simple functions makes the program easier to read, modify, and detect errors.

The next concept the author illustrates Gregory described as “command-query separation”. This means that a function should either carry out some work, or answer a question and return some data. The key advice is to not combine the two types. A function should either perform an action or answer a question, never both. If a program needed to both change data and return information, it would be better to write two separate functions to handle the tasks.

Finally, Gregory delves into the details of “loose coupling” and “high cohesion” in code. What he means by “loose coupling” is that each subsection of a program should be as independent as possible, not relying on the other parts of the code to inform a function. Similarly, the author advises us to stick to “high cohesion”, meaning that each object in a program should only contain data and functions that are relevant to that object.

Personally, I very much agree with and appreciate Gregory’s perspective and advice on writing clean code. In his advice, he very effectively clarified a lot of the concepts that I’ve trouble with implementing in my previous programs. One of my favorite lines in this post was “Large functions are where classes go to hide.” I found this quote very useful because it helps solidify the process of abstraction. From this point on, if I’m writing a function that becomes too unruly or long or complicated, I will ask myself “would this large function be better off as an independent class?” I definitely learned a lot about good practices in simplifying functions, and I will reflect on from now on when developing programs.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

“Hacker, Hack Thyself”

Stack Overflow co-founder and author of the blog “Coding Horror” Jeff Atwood writes in this post about his experience trying to secure his open source project “Discourse” from security threats. Atwood discusses the hashing algorithms they use to protect their database and users’ data, as well as the strategies they used to test the strength of their cyber security and password policies.

To test their designs, the developers attempted to hack into their own software, and track the estimated time it takes their systems to crack passwords with varying lengths. They did this by creating various passwords on the servers, starting from the most simple allowable strings of digits, increasing the length of the passwords, and moving on to more complex passwords with words and numbers combined. What they found was the passwords that combined case-sensitive letters and digits would take up to three years to crack.

By cracking the hash functions of these passwords, and recording the amount of time it took to do so, the developers had meaningful data that informed them of their software’s resilience to security threats, and presumably would have a significant effect on their password policies and development of future hash algorithms, if needed.

I found Atwood’s post both interesting and informative. It was interesting to see the strategies the developers used to protect their database from what Atwood describes as a “A brute force try-every-single-letter-and-number attack”. Still I was surprised to see how much of a difference in time it took them to crack the simple passwords compared to the complex ones.

On the technical side of things, I scratched the surface on a lot of important concepts in this post that I would love to learn more about. For instance, Atwood goes into some detail about the proper complexity and number of iterations that should go into a solid hash function. That type of knowledge is extremely valuable in developing secure programs.

Atwood concludes his post expressing a better understanding of specifically what type of attacks his software is strong and vulnerable against. I definitely agree with Atwood’s proactive philosophy about cyber security, and I believe that kind of reasoning is instrumental to being a successful software developer.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.