Understanding the Pattern of Failure

The insightful pattern discussed in Atul Gawande’s “Better” emphasizes a profound truth: recognizing and reflecting on our failures is crucial for personal and professional growth. This notion is encapsulated in the phrase “Learn How You Fail,” which posits that true ingenuity stems not from sheer intellect but from character—specifically, the courage to face our shortcomings and adapt.

Personal Reaction

I found this pattern both challenging and refreshing. Initially, it’s discomforting to focus on failures rather than celebrate successes. However, Gawande’s approach—focusing on identifying and understanding the causes of our failures—provides a constructive framework for turning apparent setbacks into stepping stones.

This perspective is not just about acknowledging weaknesses but actively choosing which battles are worth fighting. The notion that not all failures need to be addressed equally, and some might even be embraced as limitations, is liberating. It helps in setting realistic goals and focusing efforts where they can truly make a difference.

Changes in Professional Perspective

As someone aspiring to thrive in a fast-evolving sector, this pattern has shifted my thinking towards a more adaptive and resilience-oriented professional mindset. The emphasis on continuous self-assessment and setting realistic boundaries resonates deeply. It underlines the importance of focusing on areas where I can excel and accepting areas where I may never be the best. This realization takes away the useless pursuit of perfection in every domain, instead encouraging a strategic approach to skill development and goal setting.

Points of Disagreement

While I appreciate the core message of the pattern, I hold reservations about the practicality of some suggested exercises, such as writing and debugging code without initial testing. While this can reveal unforeseen errors and personal blind spots, it may not be the most efficient learning method for everyone. This approach could lead to frustration or demotivation, particularly for novices who might benefit more from immediate feedback and iterative learning.

Conclusion

“Learn How You Fail” is not just about understanding how to handle failure—it’s about strategically leveraging these insights to refine our skills, set achievable goals, and foster a mindset that views challenges as opportunities for growth. This pattern has encouraged me to embrace my limitations, prioritize my efforts, and continue pushing the boundaries of my capabilities with a clear and realistic vision.

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

For this week’s blog I decided to dive a bit deeper into writing testable code because I think it is a valuable skill. While searching for blogs that discuss this topic I found “TDD: Writing Testable Code” by Eric Elliott. In this blog, Elliott explains the importance of writing testable code barriers to writing testable code, and different tips to keep in mind to write testable code. 

The first thing he touches on is how a good quality process is essential to continuous delivery. One of the most important principles, he mentions, is the separation of concerns because “simplifies complexity and enhances the overall quality of your work”.

In the overview about testable code, he explains that achieving testable “allows for more efficient and effective identification of defects, ensuring higher quality and reliability”. The key characteristics of testable code are modularity (when code is organized into discrete units), clarity (code that is easily comprehensible), and independence (when code can be tested in isolation).One of the barriers of writing testable code that Elliott describes is tight coupling in code. The coupling in code is the instance where changing one part of the code can heavily impact or even break the functionality of another part in the code. If one part is changed there can be a chain reaction of bugs in various other parts of the code. Right coupling can be caused by parent class dependencies, shared mutable states, concrete class dependencies, event chains, state shape dependencies, control dependencies or temporal coupling. He explains that to write testable code you must reduce the forms of tight coupling mentioned because it makes testing easier and promotes a “more sustainable and scalable codebase”. This is why testable code and maintainable code are the same thing. 

Later he explains the test first vs test after approaches. The test first approach is the test driven development approach where tests are written before the code. The benefits include better developer experience and clearer requirements and design. The test after approach is where the tests are written after the implementation which leads to a probability of biased tests and reduced code coverage.

One of the last sections provided is about the separation of concerns which a  design principle for programs into distinct sections that  addresses separate concerns”. This principle is important because it allows independent testing and allows developers to isolate problems more effectively in addition to allowing the ability to make changes without unintended consequences. He describes that he likes to isolate into 3 distinct sections business and state logic (the core logic of the application), user interface, and I/O and effects (the part of the application that interacts with the database).

I think this source was well organized and easy to follow. It made the text easy to understand and provided great advice for writing testable code. I think the last section about how he likes to isolate the sections was especially helpful and I will keep it in mind for the future.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

When it comes to software development, ensuring that the final product meets the desired standards is crucial. This is where testing comes into play, and two significant types of testing are Integration Testing and System Testing. Let’s delve into what these testing methods entail and how they contribute to the quality of software products.

Integration Testing

Integration Testing focuses on testing the integration or interaction between different components or modules of a software system. In simpler terms, it examines how well individual units work together as a whole. This testing phase occurs after unit testing, where individual units of code are tested in isolation.

During Integration Testing, developers verify the interfaces between the units to ensure that they communicate correctly and exchange data appropriately. The main goal is to detect any defects or inconsistencies that arise when integrating these units. Integration Testing helps in identifying issues such as communication failures, data corruption, or incompatible interfaces early in the development process.

There are several approaches to Integration Testing, including top-down integration, bottom-up integration, and incremental integration. Each approach has its advantages and is chosen based on the software architecture and project requirements.

For more in-depth information on Integration Testing, you can refer to this link.

System Testing

System Testing takes a broader perspective by testing the entire software system as a whole. Unlike Integration Testing, which focuses on unit interactions, System Testing evaluates the system’s behavior and performance concerning the specified requirements.

In System Testing, testers validate various aspects of the software, including functionality, usability, reliability, and performance. This phase involves executing the software in an environment that closely resembles the production environment to simulate real-world usage scenarios. The goal is to ensure that the software meets the stakeholders’ expectations and functions correctly in different scenarios.

System Testing encompasses different types of testing, such as functional testing, usability testing, performance testing, and security testing. Each type of testing addresses specific aspects of the software to ensure its overall quality and reliability.

To learn more about System Testing and its types, you can visit this link.

In conclusion, Integration Testing and System Testing are integral parts of the software development lifecycle that help ensure the quality and reliability of the final product. While Integration Testing focuses on the interaction between individual units, System Testing evaluates the system as a whole. By conducting thorough testing at each stage of development, developers can identify and address issues early, leading to a more robust and reliable software product.

By understanding the concepts of Integration Testing and System Testing, developers and testers can effectively ensure the quality and reliability of their software products, ultimately enhancing user satisfaction and trust.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

The blog post, “Decision Table Testing: Everything You Need to Know”, discusses the concept of decision table testing in the software quality assurance field. Decision table testing is a systematic technique used to test the behavior of software systems against various input conditions. The blog post provided a comprehensive overview of decision tables, their components, advantages, and how they can be effectively utilized in software testing processes. In addition, the blog post offered practical insights into creating decision tables and implementing them effectively in test creation. It discussed the best practices for defining conditions, actions, and rules within decision tables, emphasizing the importance of clarity and consistency. Additionally, it provided tips for managing decision tables in a structured manner, facilitating easier maintenance and updates as the software evolves.

I chose this blog post because we have covered this topic extensively as well as incorporating a homework assignment on the topic. Due to this, I wanted to have further instruction on how this method of testing can be put to use and gain further knowledge on the method of testing. After reading the blog, I was able to gain a clearer understanding of decision table testing and its significance within software testing. Decision table testing is a very important testing method that will be a very useful tool to know and understand in use when testing for software quality assurance.

The blog highlighted the benefits of decision table testing, such as its ability to identify redundant test cases and minimize duplication efforts which are great to learn as it will help increase functionality of my tests as well as efficiency. From the blog post I was able to gain a greater understanding of Decision table testing and with that deeper understanding of decision table testing, I hope to be able to have real world scenarios that I would be able to apply the theory to. In conclusion, the resource not only expanded my knowledge of decision table testing but also equipped me with practical insights that I hope to be able to apply in my academic as well as my professional career in the future. As I continue to write and develop code for class and hopefully for career opportunities the more knowledge I have when it comes to software testing the better as it will help improve my level of design. Understanding one of the fundamental testing methods is just a step in the right direction for my career.

https://testsigma.com/blog/decision-table-testing

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.

As the title of this section suggests, it is solely focused on creating a reading list. On the surface, this section has to be the most straightforward in the book, and yet the one I practice/experience the least. With the ever-growing importance of broadening my learning through reading, I wanted to focus on this section as it feels like the obvious place to start.

Section Summary:

The idea of creating a reading list seems simple, yet so open-ended that it may also feel impossible. The section focuses on ways you can expand your reading list without feeling so overwhelmed with the endless knowledge that is available. When it comes to learning what books are important and useful enough to add to your list, it makes sense to ask mentors. Other online sources can offer reading lists from other people which may give a good insight of which books should be added to your list. The third way of finding useful sources was to pay attention to which sources are commonly referenced and cited in other readings. Seeing the same book cited multiple times can be a great indicator that it is an important book to add to your list. 

Reflection:

Having a list of which books to read next is a great way to stay organized however, having a reading list will also keep track of what books you have read. One of the points the reading made was that this list is also a reflection of your past reading habits. My list right now would reflect awful reading habits, and I must change that. When I first started to read through the patterns at the start of the semester I saw the entire chapter dedicated to reading and how important it was to broaden my education and craft with the use of reading. Starting a reading list from scratch felt like it was going to be an impossible task, with zero clue where to start or what books would be worth my time. With simple solutions provided by the reading, such as looking for likeminded lists from other people, asking mentors, and paying attention to the cited sources, I now feel way more comfortable with being able to develop my reading list.

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

The blog written by Krishna Teja Dinavahi, “Unit Testing – Is it Really Helpful?” (https://engineering.zoominfo.com/unit-testing-is-it-really-helpful) does a great job explaining the importance of writing unit testable code. What is also mentioned is how unit testing and integration testing are two different forms of testing that are both equally important. I specifically enjoyed this blog because of the great examples of code that was not unit testable along with the steps taken to refactor the code. 

What is Unit Testing and How is it Helpful?

As it’s mentioned in the blog, looking up unit testing online will give you the textbook definition, “Unit tests help you test individual parts of your application in isolation.” This is the same thing that was described to me in class, but I had the same general reaction to unit testing as Dinavahi describes. Unit testing can sometimes feel tedious and redundant. However, the real importance of unit testing is clear when you explore code that is not unit testable. Unit testing can not be done on code that is written poorly. This was the biggest eye opener for me as I read this blog, especially with the great examples provided. Notably, the one where having the external dependencies in its own function allows for easy bug fixing if anything was to change in the eternal API.

What Makes Code Unit Testable?

As I recently began refactoring old code with some of the new techniques and agile methods, I noticed the largest hurdle for me is being able to create “pure functions.” These are functions that are limited to doing one task and are very clear what that task is. From my experiences, having pure functions and good naming conventions are the two most important aspects to readable and scalable code. Approaching the code with unit testing in mind, the should automatically be written in a way that you will create pure functions. 

Conclusion

As someone who strives to write clean, readable code, I feel like I share the motivation Dinavahi expresses in the blog when it comes to learning unit testing. Each time I have refactored my code, I have always felt like it was just not finished. However, using unit testing I will be able to identify which parts of my code are not written properly and need to be refactored again. This time, with the knowledge of the steps I can take to get to unit testable code. 

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