The problem addressed by this pattern is one that should be familiar to most: needing guidance in unfamiliar ground.  The authors propose that you find a “master craftsperson” to guide you, but recognize a flaw: it is difficult to find true masters in a craft that is still fairly young, and in which the tools evolve very quickly.  Most of all, they emphasize the importance of getting over the anxiety of reaching out, because the upside of success is so high.

This resonates with me and with my experiences.  I find that I am very successful when I have found a mentor of whom I can ask questions and bounce ideas without fear of ridicule or rejection.  Even if my mentor doesn’t respond right away or have the answer, the act of formulating my thoughts enough to send them as a question to someone else can help me find what I’m looking for.

The authors also recommend taking on a mentor role when you have the opportunity.  This is also something that I’ve found helps me learn.  It may be common wisdom at this point, but I’ve found that I don’t know how much I know (or what critical knowledge I lack) until I go to teach it to someone else.  My family members often find themselves in the (hopefully patient) position of listening to me test my knowledge by explaining things to them — doing that by teaching someone that is really invested  in learning the topic is even better!

I can also connect with the anxiety of reaching out, especially to someone with whom I do not have a previous connection.  No matter how beneficial the outcome may be, and no matter what my past experiences have been (overwhelmingly positive) I tend to have trouble taking that first step of making a connection.  In my life in general, the anxiety of reaching out to other people for help is one of the largest obstacles I struggle with and one of the most important for me to work on.

Like with many of the other patterns, I find that this one did not necessarily teach me anything truly novel.  However, it validates what I thought I knew and backed that up, which is just as important.

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

“Practice, Practice, Practice” is a pattern which encourages exactly what you’d expect: continuous practice. Like Breakable Toys, the problem this pattern is intended to address is that failure in your professional responsibilities is too costly to risk. You can’t effectively learn without the freedom to fail, though, and for that reason you need somewhere safe to practice.

This is another pattern in which the writers say the ideal application of it would be in a world with formal software apprenticeship, but in reality, software apprentices have to create an approximation for themselves. In their ideal world, a mentor would assign their apprentice practice based on the apprentice’s strength and weaknesses, reinforcing what the apprentice does well and correcting their weaknesses. The writers emphasize the need for objective metrics to evaluate your abilities as a substitute for this; if you practice without getting feedback, you will reinforce bad habits.

One way of making sure you receive regular feedback is to practice in a way that’s public to some degree. The example they give is a group that meets in person to perform code katas, exercises which are meant to help programmers to sharpen their skills through repetition. For some apprentices, an activity like this probably isn’t practical or immediately accessible. Online communities devoted to practice are another option which can likely serve as a good source of feedback. Importantly, any method of getting feedback on your practice should take place in a relaxed and playful setting, since the point is to remove the stress of mandatory success. The practice itself should be something just beyond what you know you can do easily. In having to struggle with a problem, the practice will strengthen your abilities in addition to providing the benefits of repetition.

This is a pattern that appeals to me, because I’ve discovered that I learn the most by actually writing code. To that end, the writers suggest some older books that teach important programming techniques and design principles through fun problems. This seems like a useful, concrete recommendation, and I might look into obtaining one of their suggested books or find one of my own to improve my coding skills.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

In a field that continues to rapidly evolve, staying up to date with the latest and greatest tools and techniques is essential. Complacency is simply not an option if one wishes to remain competitive and relevant in the information technology field. Not surprisingly, however, there are certain tools that we become familiar over time, through repeated use and practice. There is nothing wrong with this, as familiarity with certain tools or techniques allows for more accurate estimations about work, and helps to limit risk. In Hoover and Oshineye’s Apprenticeship Patterns, they present a pattern that helps software apprentices deal with the complexities of complacency titled Familiar Tools.

In the Familiar Tools pattern, Hoover and Oshineye start out by acknowledging how valuable it is to have a set of tools that you feel comfortable using. Not only does this make you more valuable to employers, it makes the work easier and more valuable to the developer as well. From increased productivity to more accurate estimates, familiarity is important in the progression of a software craftsman.

Although the word is never explicitly mentioned, this pattern also seems to issue a warning about complacency. Hoover and Oshineye caution apprentices from becoming too set in a narrow range of familiarity, as that puts them at more risk for becoming irrelevant should the popularity or usefulness of those familiar tools fade.

This pattern was pretty easy for me to appreciate, as I already enjoy learning and improving through personal and professional development. Perhaps this desire to stay ahead of the curve is part of the reason that I became interested in the field to begin with. I have always enjoyed staying up to date with the latest and greatest gadgets, trying out beta builds, and experimenting with technology. Although the context is a bit different in the Familiar Tools pattern, the idea is very similar. The quote by Eric Hoffer that is included in this pattern also spoke to me, it is, “In a time of drastic change it is the learners who inherit the future. The learned usually find themselves equipped to love in a world that no longer exists.”

When entering the computer science program three years ago, it was repeated time and time again that the material that I would learn in college will likely be outdated by the time I am entering the workforce. While this is simply a fact of the computer science field, I feel that I am doing well at keeping myself informed and appreciate the efforts by my educators in keeping my education relevant and valuable in a rapidly changing world.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

The blog post this week discusses my favorite principle in software development, the open and closed principle. The open and closed principle encourages independencies in software development. It states the following as outlined in the article: Class behavior should be open for extension but closed for modifications. This can be separated into two parts. As explained in the article, the first part is about the behavior of a class. Extensions of behavior allows for changes in behavior to be added, deleted or modified without affecting the other behaviors. This is what is meant to be independent. Thus, the 1st part of the statement signifies changes in behavior which signifies changes in source code. The second part of the statement states that class behavior should be closed for modifications. Is this a contradiction? Modifications means changes to source code, which the second statement encourages developers not to change. This means that class behavior should be independent and not need to be modified when other parts of its behavior are changed. So, when extending a class behaviors, the source codes for other behaviors should not be changed. The other definition introduced in the article is: Software entities(classes, modules, functions, etc.) should be open for extension, but closed for modifications. The explanation for the principle is as I have described previous just above that it encourages independence in software methods.

The article, however, expresses confusion for both definitions because the two sides of the principle is a contradiction, however I think it did a pretty good job in its explanations and examples. As explained in the article, the main idea behind the OCP is that the behavior of the system can change by replacing “entities that constitute it with alternative implementations,” but that the other behaviors can be independent and therefore need not be changed. The example given is that for calculating taxes. As stated, take for example the TaxCalculator interface for calculating taxes. In this system, if we replace the UsTaxCalculator with the UkTaxCalculator, this does not require modifications of existing logic, but that it provides for new implementations to an existing interface. Overall, the main idea is that you can add behaviors to systems be adding new code, but the existing ones do not need to be changed. This creates separability so that system behavior can be easily modified and changed.

Finally, I will close this post with a discussion about 3 rules of thumb suggested in the article that can help a developer to determine when to use the open closed principle. The first is to add extension points to classes that implement requirements that are intrinsically unstable due to instability of the system. This helps to clean the code which makes it easier for modifications of system behavior. The second is to not add more preliminary extension points. Finally, the third is to refactor parts of the code and to introduce additional extension points when the parts are unstable.

Overall I chose this article in order to compare my understanding of the OCP with another software developer. In my opinion, the OCP is based on indenpendence of methods, functions and classes. Although the article indirectly refers to this point, still I think it misses to introduce this point directly.

From the blog CS@Worcester – Site Title by myxuanonline and used with permission of the author. All other rights reserved by the author.

https://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/
The last two blog posts on code review have discussed about suggestions for improvements, its overall advantages, and a general overview of what exactly it is, this weeks blog post on code review will focus on the statistics. In general, the post lists 11 proven practices based on experiments and surveys from experienced software developers that has helped team members improve code review abilities. Why is this important? Suggestions from experienced developers are based on experiences, but this post crunches up the numbers in case studies to demonstrate its effectiveness and to suggests 11 proven practices based on the statistics. This is why I chose this article this week in order to emphasize the importance of code reviews.
In my opinion, this article is one of the best I have seen so far for providing suggestions for code reviews and crunching out the numbers as well. As introduced, the suggestions from this post were compiled from code review studies and collections of lessons learned from over 6000 programmers from over 100 companies. The main issue with code review as suggested in the article is efficiency that is reviews often are too long to be practical. The conclusions from the article were from 2500 code reviews, 50 programmers and 3.2 lines of code at Cisco Systems. The study tracked the production teams with members in Bangalore, Budapest, and San Jose for 10 months.
The first suggestion is to review fewer than 200-400 lines of code at a time. The cisco code review study revealed that the optimal range for finding defects is 200-400 lines of code at a time. After that, the ability to find defects decreases. The statistics is that if 10 defects existed, it is likely that the team will find 7 to 9 of them. What is interesting is the graph shown in figure 1 of the defect density against the number of lines of code under review. According to the graph as the number of lines of code under review increases beyond 200, the defect density drops off considerably. So, the optimal effectiveness is from 200-400.
The second suggestion is to aim for inspection rates that are fewer than 300-500 LOC per hour. The inspection rate measures how fast the team is able to review codes. According to figure 2, the effectiveness of inspection falls off when more than 500 lines of codes are under review. Finally, the last interesting point is to never review code for more than 90 minutes. The article suggests that developers take enough time for a proper, slow review, but no more than 90 minutes. It is generally known from many case studies that code reviews after 60 minutes just diminishes in productivity, effort and concentration. Most reviewers simply gets tired and stop finding additional defects. Some will probably not be able to review more than 300-600 lines of codes before their performance drops. So, the rates of finding bugs deteriorates after 60 minutes. Overall, code reviews should not last more than 90 minutes.
I chose this article because the suggestions were too good to pass up a blog post. I find the first 3 suggestions to be helpful to keep in mind when code reviewing as effort always diminishes with time.

From the blog CS@Worcester – Site Title by myxuanonline and used with permission of the author. All other rights reserved by the author.

Continuing on with the TestOps posts by the, well, awesome Awesome Testing blog, is Continuous Development. Which is actually very interesting as it was a large part of what was taught in my Software Process Management course last year, so it was an enjoyable surprise to see this as the next covered topic.

Generally speaking, Continuous Development is, according to Wikipedia, “the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with software development. ”

The first step is Continuous Integration and unit tests. After every single commit by a developer, the main branch app should be compiled and built, and then unit tests should b executed to give the quickest feedback possible. The post suggests using mutation testing, testing that adds random faults to your code to see how well your tests perform, to test the unit tests themselves to see how good they are. After that, the developer should be made aware of their commit changed overall code coverage statistics.

The next step is Continuous Delivery or Automated Deployment. One should do numerous test environment deployments to test the deployment process of the application as well. After this is testing higher level things, such as functionalities on the integration or API level. End to end testing is very expensive, resource-wise, and should be done sparingly.

After that is performance testing, using a testing environment as close to the production environment as possible. You want to see how the application handles heavy loads. And then is security testing, to make sure the application is as safe from being hacked as you can manage, and then the hardest step, exploratory testing. This is a manual exploration of the application, that takes a lot of time and resources. It should be done sparingly as well.

Overall, this was another nice intersection between software development and testing. It was also a good reminder of concepts I learned in the very recent past which I found very interesting at the time. The ability to streamline the process for a developer and to give them feedback as quickly as possible is incredibly important, its ability to foster greater productivity readily available. To create such, there a many useful tools out there for testers and developers alike. Its a very straightforward example of testing directly helping developers, which is nice to see.

Original Post: http://www.awesome-testing.com/2016/10/testops-3-continuous-testing.html

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.