In this week’s blog post, I will be discussing the “Expose Your Ignorance” pattern discussed in chapter 2 of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This week, I chose this topic for my blog post because I think being able to show that you don’t know everything and can have confidence in learning is essential to growth, both professionally and personally.

This section of the chapter discusses that learning is an essential part of the development process. “Show the people who are depending on you that the learning process is part of delivering software. Let them see you grow. According to research by the social psychologist Carol Dweck, the need to appear competent is ingrained into people of most industrialized societies. These societies are increasingly dependent on your competence as a developer, as software creeps ever-deeper into our everyday lives. Yet because of your inexperience, you have many zones of ignorance. You are in a bind. The people around you—your manager, your client, your colleagues, not to mention yourself—are all under tremendous pressure to deliver software. You can see the need for confidence in people’s eyes when they ask you how long feature X will take you to finish. There can be tremendous pressure to pacify them, to reassure them that you know precisely what they want, how you’re going to give it to them, and when.” The need to appear completely in control and competent when you are new is a very difficult instinct to let go of, but it is essential to free yourself of it if you want to progress.

You must be honest with your colleagues and clients, don’ just tell them what they want to hear because what they want to happen might be impossible. “Software craftsmen build their reputations through strong relationships with their clients and colleagues. Conceding to unspoken pressures and telling people what they want to hear is not a good way to build strong relationships. Tell people the truth. Let them know that you’re starting to understand what they want and you’re in the process of learning how to give it to them. If you reassure them, reassure them with your ability to learn, not by pretending to know something you don’t. In this way, your reputation will be built upon your learning ability rather than what you already know.”

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

In this week’s blog post, I will be discussing the “Concrete Skills” pattern discussed in chapter 2 of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This week, I chose this topic for my blog post because I think being able to supplement your knowledge with practical abilities will show to future development teams that you can be a helpful addition to the teams.

The first part of this section talks about how some of the first concrete skills that you will learn will mostly entail navigating HR and team assignments, and being able to assure your team mates that you won’t need constant supervision. “Acquire and maintain concrete skills. Even though one of the things that an apprentice brings to a team is an ability to learn quickly, the possession of discrete and demonstrable ability with specific tools and technologies increases the likelihood that you will be trusted to contribute indirectly until you start to gain stature. Some of the concrete skills you should acquire will be little more than mechanisms to get you past crude HR filters and managers who construct teams by playing buzzword bingo. Others will reassure your prospective team members that you can be put to good use and will not require “day care” (Organizational Patterns of Agile Software Development, p. 88). Examples of concrete skills include writing build files in various popular languages, knowledge of various popular open source frameworks like Hibernate and Struts, basic web design, JavaScript, and the standard libraries in your language of choice.” Being able to show your fellow developers that you can stand on your own with development is a very important aspect of joining new development teams, but you must be able and willing to ask for help when you need it. The next section mentions something briefly that I think is incredible important, being able to quickly and effectively show an interviewer your concrete skills.

Being able to quickly and succinctly describe your concrete skills in a technical interview is essential. “The point is that you will often require hiring managers to take a leap of faith in choosing you. Concrete skills (which are ideally discrete enough that you can bring toy implementations to an interview) allow you to meet them halfway. The concrete skills you possess are your answer to the question: “If we hire you today, what can you do on Monday morning that will benefit us?” A deep understanding of Your First Language will help establish your credibility and should prove to be extremely useful to your team.”

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

In this week’s blog post, I will be discussing the “Unleash Your Enthusiasm” pattern discussed in chapter 2 of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This week, I chose this topic for my blog post because I think being able to properly and effectively hone your energy to be the most productive is an important skill.

The article first discusses how a new hire’s enthusiasm can be unintentionally forced down by the new hire in order to try to fit in with the development team. “Despite (and because of!) your inexperience, you bring some unique attributes to your team, including an infectious enthusiasm. Do not allow anyone to dampen your excitement for the craft—it is a precious commodity and will accelerate your learning. As a software developer, you will inevitably work as part of a team. In any group setting, there is a tendency to conform to the norm, particularly for newcomers. Most teams are not hyper-passionate or overly enthusiastic about technology. Predictably, they are focused on delivering the next project or improving on the aspects of the development life cycle that are causing them pain. Therefore, enthusiastic apprentices can often succumb to the urge to fly under the radar. They either repress their enthusiasm altogether, or allow it to manifest only outside of their day jobs.” While this is a natural reaction, it is important to be able to know when to show some of this passion to your team because, your passion is infectuous and may be able to help with team morale.

You must be careful however, depending on the team showing too much passion may work against you. “There are certainly risks involved in unleashing your enthusiasm on an established team. If morale is low or if the team is not welcoming of newcomers, you will likely get some eye-rolling behind your back. You could certainly make a poor impression on people who value competence more than learning ability, particularly when you expose your ignorance. Like any pattern, this one should not be applied blindly. Team dynamics should always be considered. If you find yourself on a team that does not accept your excitement, you will need to find ways to nurture your passion. “

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I decided to discuss the article “Unit Testing vs Test-Driven Development” by Albert Stec. I chose this article because it compliments the unit testing topic in the syllabus. This article discusses what unit testing is, why its important and how it fits into test driven development.

The first part of this article spends some time defining what a unit test is. “Unit test is usually a method that validates a small portion of the source code. So, the unit test is a programmatically written, automatic test. The unit test takes the initial data, passes it to the code under test, and asserts if the execution result is the same as the expected result.” The article then goes on to discuss what a well designed unit test should have.

The five most important parts of writing a good unit test according to the author are that it is fast, isolated, deterministic, readable and simple. “As we can see it looks simple. Although writing efficient unit tests could be complicated depending on the code we want to test. A well-written unit test should be: 1: Fast. A single project can contain a big number of unit tests, even hundreds, or thousands. Moreover, unit tests can be executed often, e. g., while developing a new feature to avoid regression or in CI/CD pipelines. Therefore, they must run as fast as possible. 2: Isolated. A unit test shouldn’t modify or depend on any external state. 3: Deterministic. A unit test should always return the same result no matter how many times we execute it. Of course, if nothing is changed between runs. 4: Readable. Unit tests are code that needs to be maintained. Therefore, it should be clear and easily understandable. 5: Simple. Often we can read that the unit test should contain a single assertion. Although it can be discussable, the fact is unit tests should validate small portions of the source code.” The next part of the article discusses the importance of unit testing in regard to software development.

This last part of the article discusses how unit testing is important to unit testing development. “To write appropriate unit tests before the logic developers spend more time on analyzing and understanding the problem and its domain. Therefore, the code is more likely to meet all requirements and clients’ needs. It’s one of the most important aims of TDD. The cycles play an important role, as the tests become more specific with time while the implementation becomes more generic.”

Article: https://www.baeldung.com/cs/unit-testing-vs-tdd

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I decided to discuss the article “Object-oriented Testing in Software Testing” by Mitali Varatiya. I chose this article because it compliments the object oriented testing topic in the syllabus. This article discusses what object oriented testing is, how you can develop test cases with object oriented testing, how to implement object oriented testing, different techniques with implementing object oriented testing, and challenges associated with the implementation of object oriented testing.

The author first discusses how object oriented testing can be done at multiple levels of a program, for example the algorithmic, class, cluster, and system levels. “Object Oriented testing can be performed at different levels to detect the issues. At the algorithmic level, a single module of every class should be tested. As discussed earlier, testing of classes is the main concern of the Object Oriented program. Every class gets tested as an individual entity at the class level. Generally, programmers who are creating the classes are involved in testing. Test cases for Object-Oriented Testing in Software Testing can be constructed based on the requirement specifications, programming language, and models.” The author then goes on to discuss how, at the class level, testing focuses on the integration of individual classes and their interactions with other classes in the program. “Once class-level testing is done, Cluster level testing will be performed. Cluster-level testing is the integration of individual classes. The main purpose of doing integration testing is to verify the interconnection between classes and how well they perform interclass interactions.” The author also discusses some ways in which object oriented test cases can be developed.

The author states that conventional methods of developing test cases are sufficient for creating object oriented test cases, but there are some features that may be helpful with object oriented testing that might be looked over when using more typical techniques on their own. “The following points should be considered while creating test cases for object-oriented environments. Which class is going to be tested should be mentioned properly within the test cases. What is the purpose of using particular test cases? What external pre-condition needs to be conducted while performing the test case? All the states should be specified for testing.” The author then discusses some of the challenges with implementing object oriented testing.

Some challenges that are associated with implementing object oriented testing as described by the author are the impossibility of dynamic testing, the necessity of different types of testing to be implemented to properly test the program, and the difficulties associated with the implementation of testing for inheritance in object oriented programs.

Article: https://www.scaler.com/topics/software-testing/object-oriented-testing-in-software-testing/

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I decided to discuss the article “A Practical Introduction to Test Driven Development” by Luca Piccinelli. I chose this article because it compliments the test driven development topic in the syllabus. This article discusses what test driven development is, the costs of using test driven development versus not using it, and gives some examples of how test driven development is done.

The author of this article is very blunt about their feelings towards test driven development. “These days you read a ton of articles about all the advantages of doing Test Driven Development (TDD). And you probably hear a lot of talks at tech conferences that tell you to “Do the tests!”, and how cool it is to do them. And you know what? Unfortunately, they are right (not necessarily about the “cool” part, but about the useful part). Tests are a MUST!” As mentioned by the other, some of the advantages that come with using test driven development are you write better software, you have more protection from breaking the whole project when new features are introduced, your software is self documented and you avoid over engineering. However, there is a glaring issue with using test driven development: the cost.

The author discusses the costs of using test driven development versus not using test driven development in good detail. The main differences in the costs are not in terms of value but in timing. “It [test driven development] costs a lot! Probably someone is thinking “but it costs even more if you don’t do the tests” — and this is right, too. But these two costs come at different times: you do TDD you have a cost now. You don’t do TDD you will have a cost in the future.” The author feels the best way to reconcile this problem is to do what comes naturally for the project’s development. “The most effective way to get something done is doing it as naturally as possible. The nature of people is to be lazy (here software developers are the best performers) and greedy, so you have to find your way of reducing the costs now. It’s easy to say, but so hard to do!” The next section I will be covering discusses how the author feels test driven development should ne implemented.

The author feels that the best way to implement test driven development practices would be to use a top down approach. “[A top down] approach is the best friend of over-engineering. You typically build the system in order to prevent changes that you think will come in the future, without knowing if they actually will. Then when some requirement changes, it typically happens in a way that doesn’t fit your structure, no matter how good it is. For me the key to drastically reducing the immediate cost of writing with TDD has been to take a top-down approach”

Article: https://www.freecodecamp.org/news/practical-tdd-test-driven-development-84a32044ed0b/

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I decided to discuss the article “Security Testing: Types, Tools, and Best Practices” by Oliver Moradov. I chose this article because it compliments the security testing topic in the syllabus. This article discusses the main goals of security testing and the key principles behind security testing, and several examples of security testing and testing tools. In this blog post I will be discussing the section on the main goals of security testing

The first section of this article discusses security testing. The article defines security testing as a series of tests determining if the software is vulnerable to cyber-attacks. “Security testing checks whether the software is vulnerable to cyber-attacks and tests the impact of malicious or unexpected inputs on its operations. Security testing provides evidence that systems and information are safe and reliable and that they do not accept unauthorized inputs.” The article also describes security testing as a non-functional form of testing, which means that security testing does not focus on the software’s functionality. Security testing fits more into the category of non-functionality testing, meaning that security testing tests whether or not the application is designed or configured correctly. “Security testing is a type of non-functional testing. Unlike functional testing, which focuses on whether the software’s functions are working properly (“what” the software does), non-functional testing focuses on whether the application is designed and configured correctly (“how” it does it). “

The main goals attributed to security testing mentioned in the article are: identify assets, identify threats and vulnerabilities, identify risk, and perform remediation. The article defines identify assets as: “things that need to be protected, such as software applications and computing infrastructure.” This is essentially what the name describes. It is about finding what needs to be protected. The article then defines identify threats and vulnerabilities as: “activities that can cause damage to an asset, or weaknesses in one or more assets that can be exploited by attackers.” Much like the prior goal mentioned, this one is also fairly self explanatory. It is about finding weaknesses within the software and possible threats that are present. The third main goal the article mentions, identify risk is defined as : “security testing aims to evaluate the risk that specific threats or vulnerabilities will cause a negative impact to the business. Risk is evaluated by identifying the severity of a threat or vulnerability, and the likelihood and impact of exploitation.” Unlike the prior main goals, which are more focused on finding specific instances of something, identify risk is about evaluating the risk being identified not finding it. The last main goal that the article discusses is perform remediation and it is defined as: “security testing is not just a passive evaluation of assets. It provides actionable guidance for remediating vulnerabilities discovered, and can verify that vulnerabilities were successfully fixed.” This main goal is also unique when compared to the prior goals because this goal is focused on finding a solution to a vulnerability.

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

In this week’s blog post, I will be discussing the “The White Belt” pattern discussed in chapter 2 of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This week, I chose this topic for my blog post because I think being able to set aside what you have learned in order to learn more is a difficult but important skill.

A quote early into this section that I can personally relate to discusses how your confidence in what you have already learned can cause you to have a harder time learning more. “You are struggling to learn new things, and it seems somehow harder than it was before to acquire new skills. The pace of your self-education seems to be slowing down despite your best efforts. You fear that your personal development may have stalled.” I have been in this position myself more than once. One approach the chapter mentions is called the not knowing stance.

The not-knowing stance, as mentioned in the chapter, is an approach to understanding that you do not and can not currently understand the entirety of what you are trying to accomplish. “Part of the approach Dave took as a family therapist included maintaining a not-knowing stance. Families in difficult circumstances were experiencing a unique reality that, despite his training, Dave knew he could not fully appreciate. While he acknowledged his skills at facilitating constructive questions and conversations, Dave was taught to refrain from believing that he had any expert knowledge into the realities that these families experienced. While this may seem counterintuitive, in reality, it fosters an attitude of respect and curiosity that opens up unforeseen possibilities and solutions. Rather than pushing solutions down on the family, Dave’s not knowing stance helped him to collaborate with the family to find solutions as a team.” As shown in this quote, embracing the not-knowing stance, can help you have a more open mind in trying to solve problems, or learn new things in different ways. Embracing the not-knowing stance is not only incredibly helpful in being able to learn new things, but can also help interpersonally, as shown by the quote.

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.