Category Archives: CS-348

The Human Aspect of Software Efficiency: Managing Your Software Team

Intro

Managing a team effectively is essential for delivering high-quality projects on time. A mismanaged team can lead to needless loss of productivity, whether it’s because of confusion between the team, or wasting time on useless tasks. This blog by Ben Brigden delves into strategies and practices that help teams collaborate efficiently, maintain focus, and deliver exceptional results.

Summary of the Source

The blog explores 9 tips of managing software development teams, but these are the main 5 I think stood out:

  1. Clearly Define Goals and Expectations: Outlining precise objectives ensures everyone on the team is aligned and working toward the same outcomes.
  2. Understand the Expertise of Your Team: Recognizing each team member’s strengths and specialties allows managers to delegate tasks effectively and maximize productivity.
  3. Protect Your Team from Busy Work: Shielding developers from unnecessary tasks helps them focus on meaningful, high-impact work.
  4. Emphasize Autonomy and Self-Reliance: Encouraging team members to take ownership of their tasks fosters independence and builds trust.
  5. Measure Performance and Strive for Continuous Improvement: Using performance metrics and retrospectives ensures progress and helps refine team processes.

Why I Chose This Blog

This Blog is a good resource that goes over the top points about working in a software team effectively. It talks about all of the aspects of being in a software team that someone might want to know to better understand their role.

Reflection of the Content

The blog emphasized that team success hinges on communication and collaboration. One point that stood out was the importance of defining goals and expectations clearly. This is probably the most important thing in a software team. Without goals the developers become aimless and don’t know what to do or how what they are doing fits into an overarching plan. This is why agile development and scrum in particular is effective, as it sets clear goals within a certain time frame, with a definition of done, so everyone is on the same page of what needs to be done and what it means for their task to be completed.

The emphasis on autonomy is probably underrated in team environments, because I think people see the word team and assume that everyone has to know what everyone else is doing. Being trusted with your own work probably has a physiological effect on productivity as well, where when someone is given responsibility, they are probably more likely to live up to their potential as opposed to if they are being babied.

Future Application

This blog has helped me better understand the ways a team should function to maximize its potential, and seeing as I plan to work in the tech industry, I think it’s valuable to know this to help myself and my future team work to our potential.

Citation

9 tips to manage your software development team (no coding required) by Ben Brigden

https://www.teamwork.com/blog/software-development-team-management/.

From the blog CS@Worcester – The Science of Computation by Adam Jacher and used with permission of the author. All other rights reserved by the author.

Good Git Resources to Help Beginners Learn

recently read the article “Git Best Practices – A Guide to Version Control for Beginners” on freeCodeCamp.org. This piece offers a comprehensive introduction to Git, emphasizing essential practices for effective version control.

I chose this article because, as a newcomer to software process management, I wanted to understand how Git can enhance collaboration and efficiency in development projects. The article’s focus on best practices provided a clear roadmap for integrating Git into my workflow.

The content delves into fundamental Git concepts, such as initializing repositories, committing changes, and branching strategies. It underscores the importance of clear commit messages and regular repository maintenance. A key takeaway for me was the significance of atomic commits—ensuring each commit represents a single, logical change. This practice not only simplifies tracking changes but also aids in pinpointing issues during code reviews.

The article also highlights the role of branching in facilitating parallel development. Understanding how to create and manage branches allows for isolated feature development, reducing the risk of conflicts in the main codebase. This insight has reshaped my approach to project structuring, making me more confident in handling complex tasks.

Reflecting on the material, I’ve realized the transformative impact of adhering to Git best practices. They not only streamline the development process but also foster better team collaboration. Moving forward, I plan to implement these practices diligently, aiming to contribute more effectively to projects and enhance overall code quality.

For those interested in exploring this topic further, I recommend reading the full article on freeCodeCamp.org: Git Best Practices – A Guide to Version Control for Beginners.

From the blog CS@Worcester – Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

Understanding Code Linting Techniques and Tools

Code linting, which provides automated tests to ensure that code complies with established standards and best practices, is an essential step in modern software development. Linting has a significant impact on the entire development process by improving maintainability, reducing errors, and increasing code quality. The TechTarget publication “Understanding code linting techniques and tools” presents a comprehensive introduction to code linting. It describes linting, discusses several linting approaches, and provides examples of typical linting tools. The essay underlines how linting can provide uniform coding standards across teams and discover errors early in the development process. It also emphasizes the importance of incorporating linting into pipelines for continuous integration and delivery, or CI/CD. Linting is an important part of ensuring high-quality software development, which is why I selected this resource. It is also directly related to the subjects covered in CS-348. The importance of clean, maintainable code and automated methods for software quality assurance is highlighted throughout the course. Furthermore, understanding linting is critical to my professional development as a software engineer, particularly as I try to improve my teamwork and coding practices. The article taught me more about linting, particularly how it helps to maintain consistency across a codebase and spot errors early on. Linting, I discovered, does more than merely check syntax; it also enforces code standards and detects potential problems at runtime. Tools like Pylint for Python and ESLint for JavaScript, for example, can detect obsolete functions, unused variables, and other minor issues that might otherwise go undetected. One of the most important lessons learnt was how to include linting tools into CI/CD processes. This integration significantly reduces the risk of production defects by ensuring that code is automatically examined for flaws before being merged into the main branch. Furthermore, the site introduced me to a variety of well-known linting tools, each tailored to a specific language and use case, such as ESLint, Stylelint, and SonarLint. The research emphasized the need of following coding conventions, particularly when working on collective projects. In my experience, inconsistencies in coding styles have hindered progress and caused confusion. A linting tool may have alleviated these issues by requiring consistency throughout the team. Going forward, I aim to incorporate linting into my development process. I’ll start my personal efforts by looking into language-specific tools like Pylint for Python and ESLint for JavaScript. I will encourage the usage of linting tools in team settings to improve code quality and speed up the review process. To ensure that the tools match the team’s needs, I want to explore creating linters to adhere to project-specific standards. Another key priority is to incorporate linting into CI/CD pipelines. By doing so, I can reduce the chance of problems in production circumstances by ensuring that the code meets quality criteria before deployment. In addition to enhancing my output, these strategies will provide me with the necessary abilities to succeed in professional software development settings.

Works Cited:
TechTarget. (n.d.). Understanding code linting techniques and tools. Retrieved from https://www.techtarget.com/searchsoftwarequality/tip/Understanding-code-linting-techniques-and-tools

From the blog CS@Worcester – Just A Girl in STEM by Joy Kimani and used with permission of the author. All other rights reserved by the author.

Waterfall 2.0

 

When looking
around the internet, I found that there was waterfall 2.0 version of the
waterfall software development methodology that we learned at start of class. After
I saw the article, I found out that even the most established practices can
transform to meet the demands of new era. Therefore, I chose this article as it
provides basic summarization of waterfall 2.0 and the difference between
traditional waterfall model. As we talked about why waterfall method was being
replaced by agile and scrum, I thought there will be some people who will try
to improve and use the old working method so using this article showed me how
waterfall transformed to adopt need of current workflow. Therefore, I decided
to look into it as a background for finding out about the improved version as
it revives the dying method into a new form.

             This
article uses baking as an example to illustrate the principles of waterfall 2.0.
It describes the steps on planning, mixing, baking, decorating and enjoying trying
to explain how they work. For example, for planning, allowing adjustments to the
cake showing adaptability, mixing; showing collaboration with others, baking;
showing continuous monitoring, making sure the cake does not burn or become too
dry etc. This shows how the 2.0 fixed many problems of waterfall. In the end,
these changes try to solve the problem of traditional waterfall model that was
not able to adopt to constantly changing environment and unexpected changes to
the requirements and need of the program.

             Reading
this article reminded me why the waterfall model is being replaced by agile or
scrum, not able to meet the industry’s demand in changing environment. Using
cake to explain the new waterfall made the concept more understandable and memorable.
The example clearly showed what the 2.0 version tries to do in order to survive.
The concept of Waterfall 2.0 was particularly impactful because it demonstrated
that no methodology is entirely outdated. If they have the right adjustments,
even traditional approaches can remain relevant in the changing world. In the
future, I thought I might use waterfall methodology in a short and brief project
that what I had to do was very clear. However, finding out waterfall 2.0 I can
try to use it for future project. For example, it could be useful in projects
with fixed deadlines and regulatory requirements, where a hybrid approach
ensures adaptability and flexibility.

Link https://de.celoxis.com/article/waterfall-is-dead-long-live-waterfall-2-0

 

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

Waterfall 2.0

 

When looking
around the internet, I found that there was waterfall 2.0 version of the
waterfall software development methodology that we learned at start of class. After
I saw the article, I found out that even the most established practices can
transform to meet the demands of new era. Therefore, I chose this article as it
provides basic summarization of waterfall 2.0 and the difference between
traditional waterfall model. As we talked about why waterfall method was being
replaced by agile and scrum, I thought there will be some people who will try
to improve and use the old working method so using this article showed me how
waterfall transformed to adopt need of current workflow. Therefore, I decided
to look into it as a background for finding out about the improved version as
it revives the dying method into a new form.

             This
article uses baking as an example to illustrate the principles of waterfall 2.0.
It describes the steps on planning, mixing, baking, decorating and enjoying trying
to explain how they work. For example, for planning, allowing adjustments to the
cake showing adaptability, mixing; showing collaboration with others, baking;
showing continuous monitoring, making sure the cake does not burn or become too
dry etc. This shows how the 2.0 fixed many problems of waterfall. In the end,
these changes try to solve the problem of traditional waterfall model that was
not able to adopt to constantly changing environment and unexpected changes to
the requirements and need of the program.

             Reading
this article reminded me why the waterfall model is being replaced by agile or
scrum, not able to meet the industry’s demand in changing environment. Using
cake to explain the new waterfall made the concept more understandable and memorable.
The example clearly showed what the 2.0 version tries to do in order to survive.
The concept of Waterfall 2.0 was particularly impactful because it demonstrated
that no methodology is entirely outdated. If they have the right adjustments,
even traditional approaches can remain relevant in the changing world. In the
future, I thought I might use waterfall methodology in a short and brief project
that what I had to do was very clear. However, finding out waterfall 2.0 I can
try to use it for future project. For example, it could be useful in projects
with fixed deadlines and regulatory requirements, where a hybrid approach
ensures adaptability and flexibility.

Link https://de.celoxis.com/article/waterfall-is-dead-long-live-waterfall-2-0

 

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

Waterfall 2.0

 

When looking
around the internet, I found that there was waterfall 2.0 version of the
waterfall software development methodology that we learned at start of class. After
I saw the article, I found out that even the most established practices can
transform to meet the demands of new era. Therefore, I chose this article as it
provides basic summarization of waterfall 2.0 and the difference between
traditional waterfall model. As we talked about why waterfall method was being
replaced by agile and scrum, I thought there will be some people who will try
to improve and use the old working method so using this article showed me how
waterfall transformed to adopt need of current workflow. Therefore, I decided
to look into it as a background for finding out about the improved version as
it revives the dying method into a new form.

             This
article uses baking as an example to illustrate the principles of waterfall 2.0.
It describes the steps on planning, mixing, baking, decorating and enjoying trying
to explain how they work. For example, for planning, allowing adjustments to the
cake showing adaptability, mixing; showing collaboration with others, baking;
showing continuous monitoring, making sure the cake does not burn or become too
dry etc. This shows how the 2.0 fixed many problems of waterfall. In the end,
these changes try to solve the problem of traditional waterfall model that was
not able to adopt to constantly changing environment and unexpected changes to
the requirements and need of the program.

             Reading
this article reminded me why the waterfall model is being replaced by agile or
scrum, not able to meet the industry’s demand in changing environment. Using
cake to explain the new waterfall made the concept more understandable and memorable.
The example clearly showed what the 2.0 version tries to do in order to survive.
The concept of Waterfall 2.0 was particularly impactful because it demonstrated
that no methodology is entirely outdated. If they have the right adjustments,
even traditional approaches can remain relevant in the changing world. In the
future, I thought I might use waterfall methodology in a short and brief project
that what I had to do was very clear. However, finding out waterfall 2.0 I can
try to use it for future project. For example, it could be useful in projects
with fixed deadlines and regulatory requirements, where a hybrid approach
ensures adaptability and flexibility.

Link https://de.celoxis.com/article/waterfall-is-dead-long-live-waterfall-2-0

 

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

Waterfall 2.0

 

When looking
around the internet, I found that there was waterfall 2.0 version of the
waterfall software development methodology that we learned at start of class. After
I saw the article, I found out that even the most established practices can
transform to meet the demands of new era. Therefore, I chose this article as it
provides basic summarization of waterfall 2.0 and the difference between
traditional waterfall model. As we talked about why waterfall method was being
replaced by agile and scrum, I thought there will be some people who will try
to improve and use the old working method so using this article showed me how
waterfall transformed to adopt need of current workflow. Therefore, I decided
to look into it as a background for finding out about the improved version as
it revives the dying method into a new form.

             This
article uses baking as an example to illustrate the principles of waterfall 2.0.
It describes the steps on planning, mixing, baking, decorating and enjoying trying
to explain how they work. For example, for planning, allowing adjustments to the
cake showing adaptability, mixing; showing collaboration with others, baking;
showing continuous monitoring, making sure the cake does not burn or become too
dry etc. This shows how the 2.0 fixed many problems of waterfall. In the end,
these changes try to solve the problem of traditional waterfall model that was
not able to adopt to constantly changing environment and unexpected changes to
the requirements and need of the program.

             Reading
this article reminded me why the waterfall model is being replaced by agile or
scrum, not able to meet the industry’s demand in changing environment. Using
cake to explain the new waterfall made the concept more understandable and memorable.
The example clearly showed what the 2.0 version tries to do in order to survive.
The concept of Waterfall 2.0 was particularly impactful because it demonstrated
that no methodology is entirely outdated. If they have the right adjustments,
even traditional approaches can remain relevant in the changing world. In the
future, I thought I might use waterfall methodology in a short and brief project
that what I had to do was very clear. However, finding out waterfall 2.0 I can
try to use it for future project. For example, it could be useful in projects
with fixed deadlines and regulatory requirements, where a hybrid approach
ensures adaptability and flexibility.

Link https://de.celoxis.com/article/waterfall-is-dead-long-live-waterfall-2-0

 

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

Waterfall 2.0

 

When looking
around the internet, I found that there was waterfall 2.0 version of the
waterfall software development methodology that we learned at start of class. After
I saw the article, I found out that even the most established practices can
transform to meet the demands of new era. Therefore, I chose this article as it
provides basic summarization of waterfall 2.0 and the difference between
traditional waterfall model. As we talked about why waterfall method was being
replaced by agile and scrum, I thought there will be some people who will try
to improve and use the old working method so using this article showed me how
waterfall transformed to adopt need of current workflow. Therefore, I decided
to look into it as a background for finding out about the improved version as
it revives the dying method into a new form.

             This
article uses baking as an example to illustrate the principles of waterfall 2.0.
It describes the steps on planning, mixing, baking, decorating and enjoying trying
to explain how they work. For example, for planning, allowing adjustments to the
cake showing adaptability, mixing; showing collaboration with others, baking;
showing continuous monitoring, making sure the cake does not burn or become too
dry etc. This shows how the 2.0 fixed many problems of waterfall. In the end,
these changes try to solve the problem of traditional waterfall model that was
not able to adopt to constantly changing environment and unexpected changes to
the requirements and need of the program.

             Reading
this article reminded me why the waterfall model is being replaced by agile or
scrum, not able to meet the industry’s demand in changing environment. Using
cake to explain the new waterfall made the concept more understandable and memorable.
The example clearly showed what the 2.0 version tries to do in order to survive.
The concept of Waterfall 2.0 was particularly impactful because it demonstrated
that no methodology is entirely outdated. If they have the right adjustments,
even traditional approaches can remain relevant in the changing world. In the
future, I thought I might use waterfall methodology in a short and brief project
that what I had to do was very clear. However, finding out waterfall 2.0 I can
try to use it for future project. For example, it could be useful in projects
with fixed deadlines and regulatory requirements, where a hybrid approach
ensures adaptability and flexibility.

Link https://de.celoxis.com/article/waterfall-is-dead-long-live-waterfall-2-0

 

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

Waterfall 2.0

 

When looking
around the internet, I found that there was waterfall 2.0 version of the
waterfall software development methodology that we learned at start of class. After
I saw the article, I found out that even the most established practices can
transform to meet the demands of new era. Therefore, I chose this article as it
provides basic summarization of waterfall 2.0 and the difference between
traditional waterfall model. As we talked about why waterfall method was being
replaced by agile and scrum, I thought there will be some people who will try
to improve and use the old working method so using this article showed me how
waterfall transformed to adopt need of current workflow. Therefore, I decided
to look into it as a background for finding out about the improved version as
it revives the dying method into a new form.

             This
article uses baking as an example to illustrate the principles of waterfall 2.0.
It describes the steps on planning, mixing, baking, decorating and enjoying trying
to explain how they work. For example, for planning, allowing adjustments to the
cake showing adaptability, mixing; showing collaboration with others, baking;
showing continuous monitoring, making sure the cake does not burn or become too
dry etc. This shows how the 2.0 fixed many problems of waterfall. In the end,
these changes try to solve the problem of traditional waterfall model that was
not able to adopt to constantly changing environment and unexpected changes to
the requirements and need of the program.

             Reading
this article reminded me why the waterfall model is being replaced by agile or
scrum, not able to meet the industry’s demand in changing environment. Using
cake to explain the new waterfall made the concept more understandable and memorable.
The example clearly showed what the 2.0 version tries to do in order to survive.
The concept of Waterfall 2.0 was particularly impactful because it demonstrated
that no methodology is entirely outdated. If they have the right adjustments,
even traditional approaches can remain relevant in the changing world. In the
future, I thought I might use waterfall methodology in a short and brief project
that what I had to do was very clear. However, finding out waterfall 2.0 I can
try to use it for future project. For example, it could be useful in projects
with fixed deadlines and regulatory requirements, where a hybrid approach
ensures adaptability and flexibility.

Link https://de.celoxis.com/article/waterfall-is-dead-long-live-waterfall-2-0

 

From the blog Sung Jin's CS Devlopemnt Blog by Unknown and used with permission of the author. All other rights reserved by the author.

Is weak copyleft the strongest? (part 2)

In part 1 we covered the different types of software licensing and how they work. Now we will be looking at why you should pick a license, how you should pick a license and which license you should pick from the plethora of options.

We will start with why you should license your software. In reality there are many reasons why you would want to put a copyright and license on your software. It is something that you created after all. It is your intellectual property and hard work. You wouldn’t want someone to steal it and use it for their own gain with no credits or regards to you. You also wouldn’t want to be found liable if someone uses what you wrote and it causes something bad to happen whether it be system breaking or cause a security breach.

As for how you license your software. There is a massive amount of licenses to choose from and you don’t need to make one from scratch. In fact it is very much recommended to use one of the many that have already been created and are easy enough to add on to what you’re working on. Leave it to the legal professionals and save yourself the time and effort.

Which license is best for you depends on your own beliefs and what you would want others to be able to do with your work. As stated in part one a closed-source project is likely something you’re doing in a commercial setting so unless you’re the business owner it won’t be your decision.

If you’re starting your own project and aiming for it to be open source and don’t care too much if its modified and has the license changed or is incorporated into an existing project under a closed-source project a permissive license will be fine. You’re still the owner and your own code is still open source. An MIT license would work for you

If you’re like me and don’t want your work to be used in a setting you don’t have insight to or the ability to decide which license is used, you may look to copyleft. A GNU General Public License would be good in this case.  

There is somewhat of a middle ground however.

Mozilla is a special case and has their own license called Mozilla Public License (MPL). It is considered a weaker copy left since it does allow developers to use their software inside of a project with a different license . Though  still requiring the portions used under their license remain under their license and be open source instead of the whole project. In my opinion, it seems to be a great blend for the future of FOSS and would be my choice.

From the blog Mikes CS 348 by Michael St. Germain and used with permission of the author. All other rights reserved by the author.