Category Archives: Software Development

Learn How You Fail Individual Apprenticeship Pattern

This week for CS448 – Capstone, I read about the “Learn How You Fail” Individual Apprenticeship Pattern, which jumped out to me as I have been considering and focusing on some of my weaknesses as I prepare to graduate and search for an entry-level position.

This pattern similarly focuses on embracing failure and weaknesses as a learning opportunity that is essential for personal and professional growth, and doing so is a crucial part of the journey of the software craftsman. Rather than looking at negatives and seeing them as a setback, “Learn How You Fail” encourages developers to confront their mistakes, analyze them/their origin, and derive valuable lessons that contribute to their ongoing growth.

By doing so in a calm, focused and organized manner, developers can really be thought of as simply taking the necessary steps to progress rather than being caught on a setback and needing to reconsider an approach (or similar). A large part of this pattern is simply mental – viewing failures as stepping stones toward mastery rather than indications of incompetence.

One of the key aspects of this pattern is the necessity of self-awareness. Developers must be able to critically reflect on their actions, decisions, and outcomes. By understanding their strengths and weaknesses, they can identify areas for improvement and take proactive steps to address them. This self-awareness also fosters humility, as developers recognize that no one is perfect and there is always room to learn and grow.

Finally, the “Learn How You Fail” pattern emphasizes the importance of perseverance. Failure can be discouraging, but it should not be a reason to give up. Instead, developers should use setbacks as motivation to keep pushing forward, armed with the knowledge and insights gained from their failures. With each failure comes an opportunity to iterate, improve, and ultimately succeed.

I particularly appreciate this pattern because I have implemented it several times successfully and have adopted it as a general approach to life. Everyone has imperfections and weaknesses, so it’s most important to acknowledge and be aware of these so we can aim to improve upon them over time and lessen their impact on our day-to-day, career, and every other aspect of our lives.

Sources: Hoover, Dave, and Adewale Oshineye. “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.” O’Reilly Media, 2009.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

A Look at Test-Driven Development & Benefits

Since just before Spring Break, in CS443 – Software Quality Assurance and Testing we have transitioned on from boundary/equivalence class analysis and onto Test-Driven Development as a strategy as well as implementation. For me, this is a huge relief and joy to get back to working on actual code rather than theoretical comp. sci. work, though it also helped me recognize the importance of non-coding exercises. 

I’ve also been really enjoying TDD as I find it aligns with my general coding habits and builds off them to help me identify new coding practices and strategies for addressing challenges. So I decided to look at some blog posts discussing it and how it’s impacted software projects versus other methods used. Test Driven Development Is the Best Thing to Happen to Software Design instantly jumped out to me.

The post discusses the significant influence of Test Driven Development (TDD) on software design. It explains TDD as an iterative approach shaping an idea into implementation through a cyclical process of ‘fail-pass-refactor’. The author illustrates the two approaches to writing code and tests: one driven by code and the other driven by tests, emphasizing the benefits of TDD in terms of mindset and code quality.

This post also considers TDD in real-world scenarios, highlighting its capacity to provide fast strategic approaches to software challenges that may seem to have no place to start (by creating tests). It addresses challenges in testing and offers solutions such as spying or mocking, managing variable test data, avoiding bloated setup, and preventing “Mocking Hell.”

Additionally, the post discusses the tendency to add unnecessary features in code and how TDD, by its nature, prevents such occurrences, thus aligning with the principle of “You Ain’t Gonna Need it” (YAGNI). This is definitely a fault that I fall victim to at times as I try to plan ahead too far in a project and add unnecessary code so I appreciate strategies to address it. Finally, it suggests that TDD not only aids in requirements meeting implementation but also serves as a technique for gathering feedback about software design, thereby advocating for Test Driven Design (TDD).

My typical strategy for developing code begins with creating a skeleton of basic components I expect to be easy to implement and then fill out the boundaries and remainders by developing minor unit tests (like print lines) to make sure it is working as intended. I sometimes do them at the same time, but I have been doing TDD sometimes without knowing it and am now better prepared to hone in on its benefits.

Source:

https://www.thoughtworks.com/en-us/insights/blog/test-driven-development-best-thing-has-happened-software-design

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Decision Tables from a Template

Over the past few weeks in CS443 – Software Quality Assurance and Testing, we’ve been learning how to apply our boundary test classes to create Decision Tables and apply somewhat similar logic to create Program and DD-Path Graphs for code segments. Decision tables are visual tools used in software testing and analysis to specify actions based on given conditions. The strategy we learned in class of assessing all possibilities then systematically combining them based on the decision outcomes and particularly “Don’t care” scenarios seems like a useful and interesting way to map out test designs.

So, I decided to look into blogs discussing Decision Tables and their implementation in software testing and found a great post on ShiftAsia with abstract and specific examples alongside general discussion. This post is also quite recent – posted on January 9, 2024 – which is something I always appreciate as the software/tech world is constantly changing. It opens by describing how to create a Decision Table by representing it with the following matrix:

Condition Stub Condition Entries
Action Stub Action Entries

Condition stub: List of all conditions in consideration

Condition entries: Filled out with Y/N (or X) to cover all possible combinations of conditions

Action stub: List of all possible actions/output

Action Entries: Marked (generally with X or blank) to show outcome and an association between a condition and result.

This is then illustrated with an example of being able to register according to conditions of having a valid email, registered email, and valid password. I found this template and example helpful to better understand Decision Tables in general by comparing them to the steps we did in our In-Class Assignment 7. And, using the example of an altogether invalid email forcing all results to be “Invalid” makes sense logically for the column consolidation.

The process of combining columns and simplifying Decision Tables is reminiscent of CS254 – Computer Architecture and Organization concepts, particularly using K-Maps to calculate Sum of Products and Product of Sums. Based on similar responses to a variety of inputs, we are able to essentially combine and simplify the K-Map table and in turn the expression it produces. While K-Map logic works based on binary math laws rather than actual outcomes, there’s a clear correlation here as we represent outcomes with boolean values that can be easily represented in binary – as either a 0(false) or 1(true). My personal experience in CS254 wasn’t the best – I didn’t totally understand how many of the concept we learned are applicable in practical situations, so it’s cool and exciting to see it applied in software testing – an area I would’ve probably least expected it.

Sources:

https://blog.shiftasia.com/use-decision-table-in-software-development

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Week 8 blog Post

For this week I found an article about writing code considering we have been writing classes for the past few classes. The article I found stuck out to me because of its title “Writing Code an Art Form”. People always use the analogy of code being like learning a new language but I never heard anyone consider it as art. From the countless articles I could have chosen without this title, I may have never chosen it to begin with.

This article first starts with a background of how the idea of this article came to be. The setup was that the author was working as a junior developer who had to get a recently hired senior developer with 10 years of experience acquainted with their program. I can only imagine how that interaction was set up and whoever was leading the group should have probably reconsidered who should help the new employee. Even though the senior developer had far advanced experience his code was not easily readable. The author was even taken aback because the senior developer commented how the author likes to write pretty code. The author goes into detail on how poor documentation must be taken into account because other flaws can arise from bad naming conventions for variables/functions, spacing, and having the mindset to problem-solve. Keep the code easy to maintain, read, and debug don’t write spaghetti code.

Now reading this article gave me insight into the inner workings of the tech field. I would have never assumed that a new employee would be getting trained by the second recently hired. I would have assumed that someone with more experience with the project would have filled in the new person but maybe it could be that there both coming from similar places. Both of them are the newest employees and could be easier to help another person adapt to the environment. Reading this article has also reinforced ideas that keep your code simple and clean. My main takeaway was whenever you write code don’t just write it for yourself to understand but for everyone. Let’s say you are working on a project on your own you might just get enclosed in how you understand code nobody but you will be able to update it. Even if you don’t care that someone else will update it in the future your code can be so unreadable that future you may have no idea what you created. In a way, code is like writing notes and there is an art to writing good notes.  

https://hinchman-amanda.mehttps://hinchman-amanda.medium.com/writing-code-an-art-form-e41e459bd2f6dium.com/writing-code-an-art-form-e41e459bd2f6

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

Breakable Toys Individual Apprenticeship Pattern

This week for CS448 – Capstone, I read about the “Breakable Toys” Individual Apprenticeship Pattern; while I did not know it when I selected this pattern, it relates back to two other patterns I analyzed earlier in the semester: “The White Belt” and “Confront Your Ignorance”.

The “Breakable Toys” pattern encourages craftsmen working in high-risk environments intolerant of failure to create personal projects, referred to as ‘Breakable Toys’. These projects are typically smaller in scope but similar in toolset to work systems, providing a safe space for experimentation and learning through failure. The pattern advises building tools like wikis, calendars, or address books, which may be overengineered but allow for trying new ideas without significant consequences. Given the book’s original publishing in 2009 and the progression and advancement of technology/platforms since then, other tools and platforms may be more applicable and resources like Git make tracking and controlling versions easy.

The focus is on personal growth, skill development, and enjoying the learning process, ultimately fostering a deeper understanding of tools and encouraging continuous improvement. In this way, this pattern is similar to “The White Belt” and “Confront Your Ignorance”, but focuses on building off of prior knowledge in a low-stress environment rather than ignoring it.

I really enjoyed reading about this pattern and its benefits as it is one of my favorites to implement – actually, while reading it I realized how many skills I have picked up using this method. As an individual, when I learn new skills/tools I naturally want to practice them and their non-instructed limitations as well as just generally play around. While a lot of what I learn may not be directly related to my initial task, I usually pick up a few things that are unbelievably useful later on and give me an advantage in addressing challenges.

The clearest example of this which comes to mind immediately is learning Apache POI and PDFBox early in my Computer Science degree/education. I had a lot of experience with basic Microsoft Office applications and was beginning to understand the power of OOP through my Java learning, so the summer after my first semester I decided to learn how to connect the two. By the end of my project, I was confident in reading/manipulating data from Excel, generating new files or report generation, format text and images in PDF documents, and more. All of this was possible because I took it upon myself to research and create my own “breakable toy” environment to learn in.

Sources: Hoover, Dave, and Adewale Oshineye. “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.” O’Reilly Media, 2009.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Another Look at Boundary Value Analysis and Equivalence Class Partitioning

Recently in CS443 – Software Quality Assurance and Testing we’ve been learning some of the conceptual aspects of code testing that are required to identify the relevant points of programs to test as likely break points. We’ve primarily learned about Boundary Value and Equivalence Class testing strategies, so I decided to find a blog to learn more about each of these from a third-party perspective. I landed upon a (relatively) recent blog on TestSigma – a (automatic) testing platform – from June 2023.

The post discusses the overall importance of software testing in ensuring functionality and reliability of software products focusing on the defining aspects of the two methods we’ve been learning: ‘Bound. Value Analysis’ (BVA) and ‘Equiv. Class Partitioning’ (ECP). BVA concentrates on testing the boundaries of a system to identify vulnerabilities, while ECP groups similar items into equivalence classes, helping testers target specific areas with a higher likelihood of containing bugs.

Benefits of applying BVA and ECP in software testing include improved understanding of the system, simplified test design, better test coverage, prioritization, and risk management. The applications of these techniques extend to various scenarios, such as database testing, network testing, hardware testing, time-based functionality, and UI testing. An interesting point that the article emphasizes is that BVA and ECP are often used together, providing an example of testing a form that accepts age as a number. It suggests partitioning the age range into groups for more effective testing while also considering likely break points.

Common challenges discussed to avoid when using BVA and ECP include restricting testing to input values alone, making assumptions about limits and classes, ignoring user behavior, over-relying on these techniques, and neglecting edge cases. The post concludes by comparing BVA and ECP, highlighting their differences in testing approaches and summarizing them as thought processes that enhance testers’ understanding of the system, leading to improved test coverage and strategy.

Test automation for BVA and ECP using tools like TestSigma (or other softwares) is also discussed, highlighting the potential benefits of saving time, ensuring accuracy, and achieving better test coverage. However, the decision to automate tests should be made considering the cost and benefit of automation and set-up.

Overall, this post taught me some interesting differences between BVA and ECP as well as reinforcing the benefits and basics we learned in class. One interesting aspect of this blog that I noticed in review is that it was written by author Apoorva Ram, a non-white woman in the computer science and specifically software engineering industry. This demographic represents a sparse minority in the computer science field and worth recognizing alongside their contribution with this and other blogs.

Sources:

https://testsigma.com/blog/boundary-value-analysis-and-equivalence-class-partitioning

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

CS448 Sprint 1 – Retrospective

This past Tuesday 2/27/2024 marked the conclusion of Sprint 1 for CS448 – Capstone. My team worked generally well together and we managed to complete all of our assigned tasks as well as some extra we added during the Sprint.

During this Sprint, I was involved in addressing a few different tasks and issues:

Issue spent most time on – “Create General and Pipeline” https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/10. This issue was in the “General” (#gitlab-profile) repository and consisted of three separate parts: 

  1. Moving settings from configuration files set up for integration with Dev Containers to .gitpod.yml extensions for GitPod integration.
  2. Refactoring the ‘commands’ folder to ‘bin’ to keep up with industry standard file naming. This includes updating script paths and .gitlab-ci.yaml environment variables to refer to bin.
  3. Adding the AlexJS linter to pipelines as well as the bin/lint.sh test script file.

Also, as a part of this issue I also implemented some minor typo and similar fixes so that all linters pass for a successful integration pipeline. Originally, these were three separate issues that were combined during the Sprint.

Issue #2 – “Familiarize ourselves with GuestInfoFrontend to Understand What Goes into CheckoutGuestFrontend”

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/37. This issue included all team members and was intended to prepare each of us for Sprint 2, during which we intend on tackling some front-end Epics/issues in CheckoutGuestFrontend. So, I reviewed the GuestInfoFrontend repository structure and began to strategize a possible plan of action for building out CheckoutGuestFrontend.

As mentioned, my Team added additional tasks to our Sprint Backlog during the sprint as we found we would have extra time leftover after completing our original tasks. We chose to take on “Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages” for the Documentation and General repositories as we had already set up the settings and thereby familiarity with these repos. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/documentation/-/issues/10

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/gitlab-profile/-/issues/12

I created our new issues; we were able to complete the task for the Documentation repo as it was relatively simple in terms of not needing to make many changes/add linters, and make some progress in the General repo but pushed the issue into Sprint 2.

Reflecting back on the sprint, there were a few things that come to mind which worked really well – as a team we scheduled out our tasks well between standups and managed to have full attendance at each. Also, when we needed to add tasks we elected to stay within the repositories we had already been working in and were somewhat familiar with, which was a good choice as switching would have likely wasted time getting familiar with the new repo, as well as wasted time for another team who would have needed to become familiar with ours. 

However, we struggled somewhat with getting used to navigating the GitLab issue board, merges, child issues etc. and sometimes it felt like some team members were in different places where a solution may not have been fully communicated to all teammates. As a team, I feel we can improve on some of our internal communication and do a better job planning out our sprints and creating something of a road map, especially as we prepare for Sprint 2 which is considerably longer than the first. Personally, I think I can improve my time management and also be a bit more involved in the process of planning out our next Sprint and creating issues with relevant descriptions and linking to organize our tasks and get a better feel of how to use GitLab to its maximum potential.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Stay in the Trenches Individual Apprenticeship Pattern

This week I continued to read about Individual Apprenticeship Patterns for CS448 – Capstone and focused on the “Stay in the Trenches” pattern. This pattern emphasizes the importance of gaining continuous hands-on, practical experience in the craftsman’s chosen field(s) at all levels, even as they may advance within a company. It can be common as software developers move up to transition to more managerial roles focusing on handling teams and deadlines rather than hands-on coding.

However, doing so will inevitably and quickly result in deterioration of the craftsman’s coding skills. Instead of getting too caught up in theoretical knowledge or managerial roles early (or at any point) in a developer’s career, developers should ‘stay in the trenches’ and continue working on practical/coding problems to keep developing and advancing skills and expertise. By immersing ourselves in the actual work, we’ll learn from the day to day experiences and continue to grow in ways that upper level managers often cannot. 

Often, I’ve heard of upper level software managers spending most of their time on coordination, time/schedule management and strategy/design planning – from a craftsman’s standpoint, only code project strategy and design planning are particularly applicable. While it surely is far more abstract and long-term or larger in scale, developers who are working hands-on with code are still managing and accomplishing tasks and exercising their code strategy and design skills. So when considering that hands-on coders will also further several other skills related to their craft, these managerial roles seem like a clear downgrade in terms of job quality and day to day activities even if it comes with a pay increase.

This brings up the final major point of this pattern, which really stuck out to me – identifying other avenues and ways for craftsmen to advance within their company/career and be rewarded for high-quality performance. Some practical examples could include a simple pay increase, more involvement in internal strategy meetings/decisions, job-title shift/improvement, etc. There’s no clear or definite answer here, but individuals in this position are probably in good standing as the company is looking to reward them, and they should communicate and work with company management to find incentives and reward mechanisms that align with the goals of both parties. If not however, this pattern stresses the importance of staying on the craftsman’s path and considering advancement positions at other companies that are more flexible.

Sources: Hoover, Dave, and Adewale Oshineye. “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.” O’Reilly Media, 2009.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Indiv. Apprenticeship Pattern: “Expose Your Ignorance”

Between sprint tasks, I continued reading Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye for Software Capstone course this week, focusing on the “Expose Your Ignorance” strategy. In professional environments, software developers are often expected to have a deep understanding of the various tools and technologies they work with, but it’s common to encounter unfamiliar domains/situations.

This strategy approaches these situations by being transparent with employers/teammates about their learning process rather than pretending to already know unfamiliar content – even if the individual is able to self-teach the content to be able to follow through. In reality, they will need to learn the new technologies/skills regardless, and transparency on this allows employers and peers to also see your learning skills and personal growth over the course of a project. 

In doing so, software developers are approaching their situation from an honest angle which is far better for building professional relationships and management expectation. In a manager role, I would much rather hear 

‘well, this API is new to me but I’m making headway in learning and implementing it. I hit an obstacle, which may delay me.’

Over an employee claiming they are an expert and then failing to deliver on time.

As a part of this, the text also differentiates between an “expert” and a “craftsman”.  While experts focus on mastering specific platforms or domains, craftsmen are driven to continually learn and adapt by broadening their knowledge base. Naturally, the craftsman can’t become a master in every topic, but master craftsmen have developed in-depth knowledge of a few separate areas of technology throughout their career and ‘apprenticeship’. So, while they may not be the absolute expert on any given topic, they will have the skills to learn, adapt and overcome challenges involving almost anything.

I appreciated this differentiation and definition of what it means to be a craftsman. Earlier this week, I had a conversation with Professor Meunier in CS497 where he described similar concepts as they relate to graduates and job applicants. As an interviewer, he/others understand that graduates will not have deep knowledge in several areas yet but looks for a wide breadth of concepts/tools we’re at least familiar with and at least one area in which we have a deep knowledge. This could be visualized as a “T” shape – wide topped with one deep portion, but master craftsmen develop a knowledge structure more like an “M”, with a wide breadth of topics and a few with deep knowledge.

Sources: Hoover, Dave, and Adewale Oshineye. “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.” O’Reilly Media, 2009.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

Understanding Test Driven Development in Software Engineering

Test Driven Development is a method in software development in which tests are created before the actual code. By writing test before hand, developers have a clear understanding of what will need to implemented, which can help avoid unnecessary errors. This approach will help to have the software behave as expected. This method is a structured and systematic approach. This test method is doesn’t just focus on testing, however it also focuses on quality and behavior. The main goal of this test method is to ensure that the code meets the specified requirements and behaves as expected. Test Driven Development helps with clarifying requirements, reducing defects, and improving the code maintainability.

How does it work?

Test Driven Development operates on a cycle like, first write a test, second make it run, third change the code to make it pass, and then repeat. Developers should first write a test that will analyze the behavior that they want implement. After running the test and writing and rewriting the code to make the test pass, developers will then need to continue reframing the code to improve it’s design and maintainability without changing it’s behavior. This process will make sure that that each piece of code is throughly tested and validate before moving on to the next.

Test Driven Development vs Traditional Testing

The difference between Test Drive Development and Traditional testing is that test driven development method has a different approach and objective. Traditional testing methods usually aim to find bugs or even defects in code, test driven development mainly focuses on making sure that the code meets the specific requirements. A failed test in test driven development method tells the developers to write new code to fulfill the requirement’s, and it also tends to make sure that the code will be lead to higher quality, with fewer defects.

There are also two levels of test driven development that focuses on different aspects of software development. Those two levels being Acceptance TDD and Developer TDD. Acceptance involves writing acceptance test that verify the overall behavior of the systems based on the users requirements. Development TDD, focuses on writing unit tests for individual components or modules of the system.

Why Did I pick this Article?

I chose this article because Test Driven Development is a very important concept in software engineering. This article has taught me a lot about test driven development , which include numerous benefits like improved quality of code, reduced bugs and fewer defects, and faster development cycle. These many advantages are valuable for any software development project.

Reflection

After reading this article, i have learned a lot about Test Driven Development and it’s many advantages. One key take away for me was how in this method developers are to write test before actually writing the code, which can help in clarifying and ensuring that the code is correct and meets the required specifications. I also found how the article talks about the difference between test driven development and traditional testing methods. Learning about the Acceptance TDD framework helped me with my understanding of how test drive development can be scaled for larger projects and integrated into Acceptance methods.

Now that my understanding has been enlighten with this new found valuable knowledge and insights into test driven development methods, I can apply this in my future software development projects. I will also be able to writer better, cleaner, and more maintainable code when using this method.

Article link is Here: https://www.guru99.com/test-driven-development.html

From the blog CS@Worcester – In's and Out's of Software Testing by Jaylon Brodie and used with permission of the author. All other rights reserved by the author.