In this blogpost, Rich Rogers, a Testing Capability Lead for Scott Logic, discusses how the people there approach testing as part of their Development and Delivery process, particularly through their 6 principles. He heavily emphasizes context as the first principle, and how when testing, things will always change. You can’t standardize testing, because every project will require different tests. In many ways, this resembles the Agile ideas that we’ve discussed in class, specifically the portion about “Responding to Change over Following a Plan”, and also goes hand in hand with another one of Roger’s principles, which is “Risks over Requirements”. I completely agree that you may be given a set of requirements as a team, and it may be satisfactory for a customer to fulfill these requirements, but there is value in looking beyond just the requirements and exploring other risks or potential problems that may not have been stated. A plan exists as a guideline, not a strict rule.

Besides those two principles, the remaining ones are: “Value in Tooling”, “Quality for Humans”, “Bring a Testing Mindset”, and “Collaborate and Cross-skill”. To elaborate, the blog discusses Value in Tooling as understanding the tools you have, and taking opportunities to run repeatable automated checks when applicable, so long as they are efficient in terms of cost and effort. Quality for Humans refers to the notion that at the end of the day, humans will be the ones using these tools. The goal is to provide something that humans will be satisfied with, and will be accessible for a person to use. In some manner, this resembles the Agile principle of Customer Collaboration, or even the Individuals or Interactions part of Agile. The Testing Mindset principle is a little more broad, in that it refers to a questioning mindset that is aligned with wanting the product to succeed. Every tester has a unique way in which they approach testing, and so long as the end goal aligns, every mindset is valid. Collaborate and Cross-Skill here refers to the notion that, while the industry encourages individual testing, understanding your team’s skills and working to complement each other can be helpful.

Ultimately, I think these principles can be summed up as be flexible, very similar to how Agile works. A willingness to understand and use tools in testing, taking the human aspect into account, a willingness to approach things differently and apply a level of curiosity and questioning, and a willingness to collaborate with others, especially those with skills and expertise that vary from yours, are all examples of disregarding the rigid plans and processes. To do your best work, you must be willing to approach anything in multiple ways and with multiple mindsets. Having chosen this blog post because of it’s insight into testing, I definitely find myself agreeing with the overall principle behind this testing approach. I don’t know how much control I will have over testing in the future, but I would certainly like to apply a similar approach to how I test things in the future.

Blog Link: https://blog.scottlogic.com/2024/10/30/our-differentiated-approach-to-testing.html

From the blog CS@Worcester – Justin Lam’s Portfolio by CS@Worcester – Justin Lam’s Portfolio and used with permission of the author. All other rights reserved by the author.

In this blog post, I will be talking about why software maintenance is important in an organization setting. The blog post that I am referencing is titled “Why Software Maintenance is Necessary,” and is published by Radixweb. The blog highlights four types of maintenance, with those being corrective, adaptive, perfective, and preventative. For each type, it is explained how it contributes to th elong-term functionality of a software, as corrective maintenance involves fixing bugs or errors, while adaptive maintenance ensures that the evolving technologies will be compatible. Furthermore, perfective maintenance focuses on enhancing the overall performance and usability of the software, while preventative maintenance focuses on lessening any potential issues before they can occur.

The blog also mentions how software maintenance is directly aligned with the goals of a business or organization. If a company were to neglect software maintenance, that would lead to vulnerabilities in their security, as well as potential technical debt. This is an interesting point, as it makes it very clear how important software maintenance is to an organization, as neglecting it would lead to major problems.

I selected this blog because it relates to our discussions in class regarding software maintenance. We touched on it in class, but I wanted to take a deeper look into it and research more about its importance. Through my research, my knowledge regarding software maintenance expanded, as I was able to learn even more about the details of it and why it is important in a professional setting.

After reading this blog post, I realized that maintenance can sometimes be overlooked in a group setting, as it becomes something that gets done automatically but is never really focused on. Maintenance kind of feels like something that is only done when something is broken, but in reality is should be something that is done regularly and often. I feel like maintenance is something that should be very high priority, as neglecting it can heavily damage companies, and can lead to bad habits of employees in a company all neglecting it, with all of them basically pushing the task to someone else instead of doing it themselves.

Moving forward, I plan to put a bigger focus on preventive maintenance in my professional career. It could be as a manager or as a team member, but I will always look to allocate time towards maintenance. This can be done in multiple ways, as you can conduct maintenance checks for compatability regularly, or even schedule audits every once in a while for preventive maintenance.

Link: https://radixweb.com/blog/why-software-maintenance-is-necessary

From the blog CS@Worcester – Coding Canvas by Sean Wang and used with permission of the author. All other rights reserved by the author.

Hi class,

For this blog post I decided to choose the topic of development environments. Development environments are one of the topics that we went over this course and furthermore, it can be interesting to find out more about it on a deeper level.

The source that I have selected is a podcast episode about remote development environments, of which the link is https://www.youtube.com/watch?v=otB0qGGmDFI. Sid Palas, the host, is an avid learner and wishes to share more of everything code to the world. In this episode he interviews Pauline Narvas, head of community at Gitpod, and Chris Weichel, CTO of Gitpod. The episode covers topics from what is a remote development environment to the inner workings of it.

Sid begins the podcast by asking Pauline what Gitpod is. Pauline replies that Gitpod “is an open source developer platform that automates the provisioning of ready to code developer environments.” This simply means that the goal of Gitpod is to remove the “friction” of the developer experiences by making the development environment more collaborative, joyful, and secure, all at the same time. 

Following this section Pauline is questioned about why someone would use a remote development environment such as Gitpod, rather than using their own laptop which has all their packages, layouts, and environments all set up. She replies the whole point of Gitpod is trying to remove the dependency of an environment. Furthermore, she goes on to state that when an update occurs, most of the time the environment does not work/delays the process of coding, while Gitpod works on automating this by saving time and mental stress. Chris goes on to add that it eliminates the “it works on my machine” issue due to the fact it will work on all participating machines because being a remote development environment, everything is in the cloud. Additionally, Chris goes on to add that the environment is more secure due to the fact your work is not secured locally on your laptop, but rather a secure cloud of which they have teams dedicated to keeping your information secure.

Pauline then is asked how to form a prospering community in the development environment of being totally remote. Pauline goes on to state she joined Gitpod in July of 2021. At the time there were multiple outlets of conversations throughout developers by using GitHub, X (formally known as Twitter), Discord, and other chat applications. She realized this was not effective at all for communication, so her role was to try to streamline the community together due to the fact the community was scattered throughout multiple channels. At the time there was not a central place for the community to come together. From here, the Gitpod community was created, which has been found to be a great central hub for developers to come together. Pauline stresses that having an open outlet of discussion amongst peers is crucial to a development environment, remote or not.

Lastly, Sid addresses the security of Gitpod and what it looks like from an inner perspective. Chris states it’s a forever evolving process, but the most important key is creating a team(s) that thrives. Chris goes on to state that you must give the team enough space to act, yes, but also build a team that knows the space, is knowledgeable and drives to keep learning about the forever changing space. 

My personal comments about this is that I found this to be really insightful. Throughout the interview I felt like they were not simply just having a podcast, but talking to me as a viewer. As a fairly new programmer, I have not been exposed to the extent of Gitpod as other programers have, but what they did with Gitpod, I can see why a lot of programmers use it. Gitpod saves a lot of time in a development environment and less stress of hearing “it works on my machine”; it will work on everyone’s. Furthermore, I have been kind of intimidated by Gitpod, but after listening to this I am eager to use it more often when doing coding projects whether that’s by myself or with a team, it seems like a really great tool that I should be more involved in. 

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

For my third blog, I will explore software maintenance and its important role in the SDLC process. Maintenance is typically the last step because these updates and tweaks are made after the finished product. We have touched on the SDLC process and scrum during our in-class activities and examined both their differences and similarities. I found this source that goes into more detail about software maintenance while explaining the different types of maintenance.
For the most part, maintenance in our in-class discussions for the SDLC process was a period of bug fixing or adding new features the customer wanted in the software. The blog lists two more reasons why maintenance should be altered, whenever a policy changes or if there is a business-level change, like an acquisition of another company. In our in-class discussion, we mainly went over two types of maintenance, corrective maintenance, which consists of updates correcting problems found by an end user, and adaptive maintenance, which consists of keeping the program up to date. A new type of maintenance I haven’t thought of but the source pointed out was preventive maintenance, updates that aim to prevent future problems of the software. Some examples of preventive maintenance can be regular cleaning of code or replacing outdated sections and updating them with newer code.

The source then goes on to talk about the costs of each software process cycle, and this section caught me by surprise. It goes on by stating a study found that maintenance can be as high as 67% of the cost of the total software process cycle. I always thought that designing or testing would have a bigger slice of the cost rather than maintaining, but the source again highlights that on average the cost of software maintenance is more than 50% of all SDLC phases. It then goes on to give some context or some reasoning why this phase can be so expensive, the standard age of software can be up to 10 to 15 years which creates a commitment to pay to upkeep them, the structure of the program, the language used in the programming, and changes that are made are often undocumented which leads to problems in the future.

This source did a good job of going in-depth with the maintenance stage of the SDLC process we learned in various in-class activities. It gave me a new sense of where most of the budget goes during the SDLC stages while explaining that each type of maintenance is varied by its nature and characteristics. If you would like to know more about the most costly phase during the SDLC then I would recommend reading.

Source: https://www.tutorialspoint.com/software_engineering/software_maintenance_overview.htm

From the blog Mike's Byte-sized by mclark141cbd9e67b5 and used with permission of the author. All other rights reserved by the author.

Hi class,

For this blog post I decided to choose the topic code review. Code review is one of the topics that we went over this course and furthermore, could be very beneficial for all of us to learn even more how code review is executed.

For my resource of code review I listened to a GOTO Conference talk in Berlin and here is the link to the video: https://www.youtube.com/watch?v=ly86Wq_E18o&t=142s. The video is of a man named Alejandro Lujan, who has been a software developer for more than 20 years. Alejandro goes on to state he knew code review, but not to the extent from when he got his most recent job at Shopify. It was here at Shopify his aspect of code review vastly improved. (I chose a video format because I like listening to the speaker better; I can understand said topic more with a personal connection.) 

Alejandro’s first couple months at Shopify was not what he expected. The code reviews were a lot more “harsh and intense” than what he was accustomed to. Alejandro took the code reviews very personally, thinking he is a bad coder and maybe the team does not like him. After pondering these thoughts for a couple of months, he looked at the work he was contributing and the comments were not about him, but rather his work. He quickly realized the code review at Shopify was not simply just a code review and then Alejandro went on an arch to fully understand code review.

Through the following months, he realized that great code reviews are symptoms and contributing cause of highly effective teams. From here there are two sets of people in the equation, the author(s) and the reviewer(s). From here, he would state that there are four important aspects to code review which are building the right thing to achieve an objective, building it correctly, fast, and together.

For building the right thing to achieve an objective. He goes on that from the very early stages of coding, you should show proofs; this will ensure you are on the correct path and if not, it’s an early change to fix. 

Building it correctly involves utilizing GitHub and all the features it has. Alejandro states you must label work correctly. For instance rather than using a PR use a draft PR on GitHub. Along with this, GitHub has a feature stacked PR; several PRs are reliant on each other. He states that wanting a deeper code review, this is a must rather than have all PR’s in one. He also acknowledges it’s possible to create too many small stacked PRs but still has yet to encounter this. Stacked PRs are a powerful technique and should be implemented in code reviews to help team projects. Lastly, to ensure your commits are easy and understandable.

For building it fast he states by doing the above, it’ll be faster in the long run rather than sprinting to try to get the code done all in one commit without any peer review prior. Showing proofs/feedback and using stacked PR’s on GitHub; taking it one step at a time to achieve the goal.

Building it together means you need to have a team oriented mentality. How can WE improve this thing, not how can I improve this thing. Along with this, you should provide actionable feedback to other teams, rather than “this is not great” provide a direction of how things can get better. Alejandro also acknowledges that too many people in a meeting/code review could not always be beneficial. You as the author need to question if it would be beneficial to have the feedback of everyone and have a 10 person conversation in GitHub, or rather to include two people only who are skilled in said task. If it’s more beneficial to only have a few people, make sure the results of the conversation are reflected on the PR.

Alejandro then goes on to wrap up his talk with five takeaways:

1. Keep PRs small
2. Share drafts early
3. Focus on the work, not the person
4. Offer actionable feedback
5. Pick the right people

From understanding and implementing these takeaways, the code review will be a lot more deeper in the understanding of why something is being changed and also the importance of a great code review. 

My personal comments about this is that as a developer you are always learning and will never be “done” in terms of learning. Furthermore, as a developer you must be willing to adapt quickly. Alejandro had twenty years under his belt and then coming to a new job seemingly had his world flipped upside down, but rather than being timid, he adapted. Along with this, at the beginning he was talking about taking his coworkers comments personally, which was not the case at all then after realizing this, he strived forward. I think this is a great story and has taught me that to be in this field, you must be adaptive and code review is simply not “code review” but rather steps and processes compiled to make code review.

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

Clean code is an important aspect of a software developer’s skill set. It means writing code that works well, and is easy to read, understand, and maintain. Three key principles of writing clean code are conciseness, reusability, and a clear flow of execution. Each principle in its own way contributes to the ease with which the software development process proceeds and the reliability of the end product.

1. Striking the Right Balance Between Conciseness and Clarity:

Finding the right balance between writing concise and clear code is very important. Concise code can make the codebase easier to read and it reduces the amount of time spent writing it. However, being too concise can make the code difficult to understand. The goal is to keep the code brief but also easy to read and understand without losing its purpose or logic.

2. Reusability

Another important principle of clean code is reusability. Writing code that can be reused in different parts of an application or across different projects saves time and reduces redundancy. Reusable code leads to a more modular structure, which makes the codebase easier to maintain and enhances its flexibility. It not only speeds up development but also makes it easier to fix bugs and make future updates.

3. Explicit Flow of Execution

A clear flow of execution is one of the critical characteristics of the code that guarantees its readability and ease of maintenance. A not well structured code leads to a condition where it is difficult to maintain a project. A logical and straightforward flow of code is easy to perceive by a developer, which is necessary for the code support during the whole life cycle.

4. The Single Responsibility Principle (SRP)

Every module or class should have only one responsibility. This decreases complexity, thereby making the code base manageable. Testing  and debugging, with development and improvements for future maintenance, are all greatly simplified, hence, the software becomes easier to use and much more understandable.

Conclusion

The balance between conciseness, reusability, clear execution, and following the Single Responsibility Principle will definitely allow developers to write clean code, benefiting the whole process of software development. Clean code is not simply error avoidance, but also it improves collaboration inside the team, makes life easier for new developers, and significantly increases the speed of code reviews. This will definitely result in efficient, maintainable software with easy adaptation to changes. Keeping these principles in mind allows me and other peers to create software that is functional, yet high quality and user-friendly. Even though we have done Clean code in Software process management class, reading this article helps as a reminder for writing code as best possible and also comes with examples which I did not include not to make this blog post too lengthy, but I suggest everyone to go and read it.

Citations:

https://www.freecodecamp.org/news/how-to-write-clean-code/

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

Hello everyone

For this week’s blog topic, I will talk about Agile Methodology. This was one of the earliest topics we went over in this class but to me it was one of the most important one to understand and to remember. This blog explained and went over the main concept of it, going over in detail its values and principles, benefits, the implementation process and why it still remains as the favorite choice across the computer science field. Its main focus is on keeping things simple, adapting as the situation changes. Its foundation is highlighted in 4 key values:

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

These important values are supported by 12 core principle, where they emphasize the importance of adaptability, welcoming change and also increasing the communication between the programming team and the business partners which they are working with. This allows them to give a final product which meets every expectation of the customer, even when they decided to change or tweak some things in the middle of the process. This methodology encourages improvement, teamwork, communication while prioritizing efficiency and delivering a high-quality project/product. The workflow off Agile is pretty simple and it is easily explained through its six lifecycle stages: Concept, Inception, Iteration, Testing, Production and Review. Usually, teams complete their work in sprints. Each sprint most of the time lasts about two weeks. There are multiple checkpoints throughout this time, allowing the team to change direction if needed. This is extremely important as sometimes the customer changes its idea on how they want their product to work or to look so having these checkpoints, makes these changes possible. By continuously checking up with the requests of the customer and showing drafts and previews of how the product will look, this allows them to deliver a better final product. The reason why I chose to do this week’s blog in Agile Methodology is because it has become the gold standard in project management and software development, so it was important for me to learn it well as soon enough I will be working with it after I graduate.

To summarize everything, Agile is more than just a methodology; it’s a mindset that encourages teams to adapt, not be afraid of new changes or request and to deliver the best possible final version of the product, meeting each request given by the customer. By valuing collaboration, flexibility, and efficiency, Agile Methodology creates a strong team environment, where each person on the team feels like they are contributing something essential to the project. Just reading about it, it motived me to uses its key values and principles on my life, making my productivity even better as that is something I struggle at times.

Lucid Content Team. “Agile Methodology and How You’re Already Using It.” Www.lucidchart.com, 13 Sept. 2017, http://www.lucidchart.com/blog/what-is-agile-methodology.

‌

From the blog Elio's Blog by Elio Ngjelo and used with permission of the author. All other rights reserved by the author.