CS-448: Week 14

Retreat into Competence

This pattern is about how it is easy to get caught up in constantly learning new technologies due to the fast pace of software development, and how to manage the intense pace of learning. The pattern highlights the importance of taking a step back from the fast paced learning and to focus on honing existing skills. Trying to learn the latest tools, frameworks, and methodologies can be overwhelming. Along with the overwhelming feeling of trying to learn many skills at once, there is also a risk of never fully mastering the fundamentals. Therefore it is important to take a step back, and take time to practice fundamental skills.

According to the pattern, being an apprentice is a rollercoaster ride. This is because there is the thrill using newly learned skills to deliver value to the customer, but there is also the terror of realizing how little is known compared to more experienced craftsman and experts. However both are normal and inevitable experiences.

Although the pattern encourages developers to take a break from learning new skills, it also emphasizes how retreating back to competence is to not get stuck in the realm of competence. It is important to be intentional when retreating, as this pattern is only a short term fix. Spending too much time on this pattern can lead to halted learning. Being able to learn something new is a skill in itself; therefore, learning should be practiced unlike any other skill.

In order to prevent the pattern being used, setting a time limit for honing new skills is useful. This is so one does not focus too much on retreating, and helps them stay in the habit of learning new skills. A strategy the pattern suggests is to pick a well understood topic that is self contained, and to reimplement it. This can help regain confidence to propel learning.

Conclusion

I found this pattern to be interesting as constantly learning new technologies can be tiring, so having a strategy to regain confidence is helpful for the future. I particularly enjoyed the analogy of a catapult to represent this pattern. The analogy being that the skill of learning new topics can be launched forward by taking a step back. The pattern has changed the way I view learning new skills, and maintaining old ones.

CS-443: Week 14

Behavior-Driven Development (BDD)

Behavior Driven development is an approach where the focus is set on the behavior of an application for the purposes of a business. This focus is to find a common ground between developers, quality assurance teams, and business professionals. Common ground is found by defining behaviors that are written in plain language, allowing everyone to understand and agree upon the software’s behavior.

BDD Process

Behavior driven development begins with defining behaviors in “feature files” which are used throughout the development process. Behaviors are straightforward statements that outline a specific process in a predetermined format.

Behaviors are written in a language called Gherkin, which use simple words such as “Given”, “When”, and “Then.” An example behavior would be, “Given the user enters an incorrect password, When they click the login button, Then they should be prompted with an error to reenter their password.” These behaviors are turned into tests with tools that check if the software behaves as intended. Because everyone is involved in this process, and agrees on the final product, confusion can be avoided.

Advantages to BDD

Behavior driven development leads to advantages that would otherwise be lost with other development approaches. A key advantage with BDD is better communication and collaboration. This is due to the nature of BDD as everyone from business, to quality assurance, to developers, meet together and plan everything. Because there is better communication, requirement understanding also increases. This is because requirements are explicitly defined, and everyone agrees what should be done. Due to the increase in requirement understanding, testers are made aware exactly what requirements should be tested. Ultimately the chances for the final product to be different than what was intended is less, saving time and effort.

Disadvantages to BDD

Because BDD is different from other development approaches, adopting the practice can be difficult. This is because teams are used to working amongst themselves, then meeting with the other teams once a final product, or an iteration of the final product has been completed. Waiting until a product has finished development before meeting the other teams can lead to wasted time and effort because what is actually delivered may be different than what the business team intended. Another reason why BDD can be hard to get used to is the overemphasis and learning curve with the tools necessary for BDD. Teams can get off track because they get caught up in learning Gherkin syntax and other tools.

Conclusion

This article was chosen because topics were easy to understand with the use of real world examples. Once past the learning curve, behavior driven development seems like a useful approach that fosters strong collaboration and communication. I was unaware of tools like Gherkin and Cucumber that are used to process the feature files, so learning about them was interesting. This approach is unlike others I have seen in the past; however, I am curious about how is all works. I will be looking into these tools in the future.

Resources:

https://www.browserstack.com/guide/what-is-bdd

Week 14: CS-343

Design Patterns

A design pattern is a general solution that can be used to solve commonly occurring problems in software design. A design pattern cannot be put directly into code, rather it is a template of how to solve a problem that can be used various situations.

Design patterns are helpful as they speed up the development process by providing proven examples to be used as a reference for common problems. When designing software, small subtle issues can build up leading to major problems that can only be seen during implementation. Using design patterns can help prevent these subtle issues from occurring which reduces the likelihood of major issues occurring.

Because design patterns are tested, proven, and commonly used, patterns also allows for better communication among developers by using well known and understood names for software interactions.

Types of Design Patterns

Creational

Creational design patterns cover class instantiation. These patterns can be further divided into two classifications, class-creation and object-creational patterns. Class creation uses inheritance in the instantiation process, while object creation uses delegation to create objects. Some creational design patterns are:

• Singleton
  • A class where only a single instance can exist
• Factory Method
  • Creates an instance of several derived classes
• Object Pool
  • Avoids expensive acquisition and release of resources by recycling objects that are no longer in use

Structural

Structural design patterns are about class and object composition. Like creational patterns, structural patterns can also be broken down into class creation and structural object patterns. Class creation patterns use inheritance to compose interfaces, while object patterns define ways to compose objects to obtain new functionality. Some structural patterns are:

• Adapter
  • Matches interfaces of different classes
• Private Class Data
  • Restricts accessor/mutator method access
• Decorator
  • Adds responsibility to objects dynamically

Behavior

Behavior design patterns are about how objects communicate with each other. Some examples of behavior design patterns are:

• Null Object
  • Used to act as a default value of an object
• Chain of Responsibility
  • A way of passing a request between a chain of objects
• State
  • Alter an object’s behavior when its state changes

Conclusion

This article was chosen because it clearly described what design patterns are, what they are used for, and gave examples of the different types of design patterns. As stated before, not only does the usage of design patterns help with preventing major issues, they also allow for better communication among developers which is essential to a team’s success which is why I chose to write about design patterns. As I continue to design software, effectively using design patterns will become more and more prevalent, so learning about them now will only be beneficial.

Resources:

https://sourcemaking.com/design_patterns