https://www.codingame.com/blog/agile-failed-peek-future-programming

This blog post by CodinGame provides a short history of development methodologies and goes on to make a critique of specifically Agile. It describes how, despite how widespread the methodology has now become, Agile has generally not succeeded as a methodology because of how it has been implemented by corporate management teams. While Agile as a methodology strives to be a set of principles that should guide a team to good practice and a healthy work environment, non-programmers use it as a tool to enforce hierarchical structures and rigid development. Most of what is said can likely also be applied to Scrum, but it is not explicitly mentioned.

This blog interested me because when I learned about Agile and Scrum, I always thought to myself, “Why would you ever not choose these methodologies? These seem far superior to outdated methods like Waterfall.” However, this post opened my eyes to how Agile really only works when implemented as was expected by those who wrote the manifesto. This post makes it very clear that what makes a methodology successful, or a team successful in general, is understanding its intent and being able to reflect on if its intent aligns with the work style of the team in question. Generally, I feel that if you’re a business leader who wants to have a rigid plan, then you should just follow a rigid plan like that of Waterfall, rather than creating a fake team experience with a smoke-and-mirrors version of Agile.

The post helped me reflect on what to look for in a well-functioning team. I think these insights can be very valuable for someone when they are looking for a place of work, as when you apply these critiques as a tool to analyze employers, it may be very apparent at some point in the process when a team is run by a group of developers and when a team is run by non-programmers enforcing a strict hierarchical system of development. I think this kind of resource would also be useful if ever in a position where one’s input is valued when evaluating how a team should handle itself, as it can be helpful in recognizing what are good tendencies in a team and what are bad tendencies, especially in a leadership position where hearing the whole team’s voice can be valuable. Being able to express why a decision may be bad is not only valuable for working in a team but also for working under management, as articulated thoughts may be enough to have an impact on their perspective as well.

This blog highlights the importance of understanding and respecting the intent behind methodologies like Agile; it serves as a notice of how we need to hold ourselves and team leaders accountable for how a team chooses to go about development.

From the blog CS@Worcester – CS ZStomski by Zachary Stomski and used with permission of the author. All other rights reserved by the author.

After our recent studies relating to Docker managing dependencies and ensuring consistent development environments, I was interested in learning more about how to use it because I thought something like this could have saved me many hours of troubleshooting while completing a recent research project. This article, written by Medium user Dispanshu, highlights the capabilities of Docker and how to efficiently use the service in a cloud environment.  

The article focuses on optimizing Docker images to achieve high-performance, low-cost deployment. The problem some developers run into is having very large images which slow the build processes, waste storage, and reduce application speeds. I learned from this work that large images result from including unnecessary tools/dependencies/files, inefficient layer caching, and including other full images (like Python in this case). Dispanshu focuses on achieving the solution in 5 parts: 

1. Multi-stage builds 

2. Layer optimizations 

3. Minimal base images (including Scratch) 

4. Advanced techniques like distroless images 

5. Security best practices 

Using these techniques, the image receives a size reduction from 1.2GB to 8MB! The most impactful change being multi-stage builds to which the writer accredits over 90% of this size reduction. I have never used these techniques before, but my interest definitely peaked when I saw the massive size reduction that resulted from these changes.  

The multi-stage builds technique references the build stage and the production stage. By using this technique build-time dependencies are separated from the actual runtime environment which avoids the inclusion of any unnecessary files or tools in the resulting image. Another technique recommends minimal base images using the slim or alpine version (for Python) over the full version for the build stage and for production stage it is recommended to use the scratch base image (no OS, no dependencies, no data or apps). Using a scratch image has pros and cons, but when we are considering image sizes and optimization this is an ideal route. 

Another interesting piece of this article is the information relating to advanced techniques like distroless images, using Docker Buildkit, using .dockerignore file, and eliminating any excess files. The way that distroless images are explained by the writer makes the concept and the use case very clear. The high-level differences between the Full Distribution Image, the Scratch Image, and the Distroless Image are described as the different ways we can pack for a trip:  

1. Pack your entire wardrobe (Full Distribution Image) 

2. Pack nothing and buy everything at your destination (Scratch Image) 

3. Pack only what you’ll actually need (Distroless Image) 

The analogy makes understanding the relationship between these three image options seemingly obvious, but I can imagine applying any of these techniques described would require some perseverance. This article describes an architecture that juggles simplicity, performance, cost, and security with very impactful results. The results of this article are proof of the value these techniques can provide, and I will be seeking to apply them in my future work.

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

This week, I will be talking about the “best” Linux Distro you should learn in order to get the most out of your hacking. This topic is widely debated and you will get many different answers from asking around, with people claiming different distros to be the “best.” Although that title can be slightly arbitrary, there are some specific distributions of Linux that are objectively better or overall more suited for hacking.

Kali Linux is often regarded as one of, if not the best distros to learn for hacking, because it was specifically designed for digital forensics and penetration testing. Developed by Offensive Security, this Debian-based distro remains a favorite among coders and hackers, and comes loaded with security testing tools, powerful programs, and applications that make life easier for people who want to become a hacker (or are one already). Although it can be a bit overwhelming, Kali is extremely helpful for beginners, because all of these tools are laid out for you and it helps you learn right away how to use them and what their capabilities are.

In the podcast, John mentions that he typically uses Ubuntu, and that he has people who ask, “John, why are you using Ubuntu when you could have been using Kali or Parrot OS?” He responds, “I think it’s really valuable to learn how to install those tools, learn how to configure those tools, watch, and see them break–because then you’ll be able to figure out how to fix them, and you’ll be able to troubleshoot and understand what are the packages, what are the repositories, how does this all work within Linux.” He believes that getting through the learning curve is worth it because it will ultimately be good for your own learning and growth. At the end of the day, each distribution of Linux is going to have its own strengths and weaknesses, and will be a little different from each other. Having knowledge and experience about these tools will allow you to use them when solving problems and will make you a better hacker.

I have never experimented with Kali Linux before, but I do have some experience when it comes to learning about hacking through Linux. There is a special, custom-made distribution of Linux called Tails, and like Kali, it is based on Debian. However, there is a very big difference between these two distros; while Kali seems to focus more on offensive hacking, Tails is more defensive and prioritizes both privacy and security through its unique interface. It is made to be booted as a live DVD or USB and never writes to the hard drive or SSD, instead using RAM, and leaves no digital footprint on the machine (unless told otherwise).

In conclusion, Linux is still somewhat unfamiliar to me, as I only have limited experience. I would like to learn more about Kali Linux in particular, but would also like to explore other distributions and learn about their potential.

Watch it here:
https://www.youtube.com/watch?v=T7AaBcNj-mA

From the blog CS@Worcester – Owen Santos Professional Blog by Owen Santos and used with permission of the author. All other rights reserved by the author.

This week, I found an article that actually only recently came out about 8 days ago. The article, titled “Academic papers yanked after authors found to have used unlicensed software”, dives into two authors who had their paper retracted from an academic journal because of their use of a software in which they did not obtain a license from.

The authors used a software called “FLOW-3D” to help them calculate results exploring dam failures. When the parent company, appropriately named “Flow Science” found out about this, they made a complaint and were quickly able to have the papers taken down by  Elsevier’s Ain Shams Engineering Journal. The journal’s editor-in-chief even stated: “One of the conditions of submission of a paper for publication is that the article does not violate any intellectual property rights of any person or entity and that the use of any software is made under a license or permission from the software owner.”.

I find this to be an important issue that should be certainly talked about. This semester, we already learned of the importance of obtaining these licenses for a multitude of reasons, but I don’t believe we saw any real life examples of consequences if you didn’t. This article shows that, especially if required by a certain company, journal, or any sort of entity, using software or creating software and not properly getting a license for it can have repercussions. While I’m unsure if I’ll be writing an academic paper in the near future, I imagine at some point, if I further my education, I will. And if I do, and I need to use software in a similar manner to the people in the article used it, I will certainly make sure I am not breaching any sort of guidelines or laws set in place when it comes to the software licensing.

The article also mentions that, in 2023, over 10,000 research papers were retracted, which is a new record. I’m unsure if these were all due to licensing issues or if other issues were involved as well, but it still proves the point that it is taken very seriously and you can face the repercussions if you are not careful.

There are also many other types of consequences you may face by not getting licenses when it is necessary, but I think this article may be a good one to read especially if you plan on writing a paper or study at some point with which you used software to help solidify your paper. It is always good to be aware of what you need to do to be able to appropriately write a paper first, so you don’t have to deal with potential consequences if you don’t.

From the blog CS@Worcester – RBradleyBlog by Ryan Bradley and used with permission of the author. All other rights reserved by the author.

We spent a lot of time in class going over the different types of software licenses and the reasoning for why they are necessary, so I figured that it would make sense to dig deeper into the topic.

The blog that I selected introduces software license management as a way to strategically optimize and manage the usage of software within a company or organization. The blog post defines software license management (SLM) as the process of ensuring compliance within software licensing agreements but also minimizing any overspending and inefficiency throughout the entire process. The blog post also mentions the reasons for why SLM matters, as it points to the overall operational benefits that comes with proper SLM as well as the general legal and financial risks that are associated with non-compliance. Throughout the blog, the various types of licenses are all mentioned and explained, such as open-source, copyleft, and permissive licenses.

I selected this blog post because of its relevance to what we learned in class, as it gave a refresher on software licenses and also gave further elaboration on the overall subject. This blog also shows why software license management is important to a company, as it often leads to an increase in overall operational efficiency as well as compliance efficiency. This could be useful for me in the future as this article explained the importance of SLM in a workplace environment, which is very useful context to have.

This article gave me a larger understanding of software license management and the benefits of it. It also helped clarify my understanding of how companies tailor their strategies based on their operational needs, as the differentiation of software license types made this clear to me. I was very intruiged by the risks of not having SLM, as this can lead to a lot of inefficiencies as well as costly penalties for an organization, which is something that I never really considered thinking about. At the end of the article, it shows and lists a bunch of automation tools for SLM, which I found very interesting. This made me think about how technology can really simplify complex tasks, which can be both beneficial and detrimental at the same time for my future. For my future, I intend on applying this knowledge of software licenses and SLM potentially in future workplaces. To me, the benefits outweigh the negatives as implementing SLM will only increase efficiency within the company, which I think is generally a goal for most companies. Overall, this blog post did a great job at explaining the different types of software licenses, and showing me why software license management is so important, as well as why it is necessary when it comes to overall efficiency within an organization.

Source: https://whatfix.com/blog/software-license-management/

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

This week, I explored the article “GitHub Copilot Moves Beyond OpenAI Models to Support Claude 3.5, Gemini” on Ars Technica. It discusses GitHub Copilot’s recent expansion to integrate advanced AI models like Anthropic’s Claude 3.5 and Google’s Gemini, diverging from its earlier dependence solely on OpenAI. This development is a pivotal moment for AI-driven coding tools, as it allows GitHub to offer developers more diverse and powerful AI models tailored to different tasks.

The article highlights how GitHub Copilot, widely known for assisting developers by generating code snippets and reducing repetitive tasks, is evolving to deliver greater flexibility and efficiency. The inclusion of Claude 3.5 and Gemini enhances Copilot’s ability to handle more complex coding tasks, such as debugging and system design, while maintaining security standards. This shift also underscores GitHub’s focus on model diversity to better cater to developer preferences and workloads. Beyond coding, Copilot’s broader goal is to support the entire software development lifecycle, including planning and documentation.

I chose this article because our course emphasizes practical applications of programming tools and their role in optimizing workflows. GitHub Copilot, as an AI coding assistant, directly relates to concepts we’ve discussed about improving productivity and leveraging technology in software development. Additionally, we’ve been learning about programming tools and techniques that prioritize efficiency—qualities Copilot exemplifies. Understanding these cutting-edge advancements gives me insight into tools I may encounter in future projects or internships.

What resonated most with me was the article’s emphasis on customization and adaptability in AI-powered development tools. The idea that developers can now choose AI models best suited for specific coding challenges is intriguing. I also appreciated the focus on how Copilot is being adapted to aid more than just coding, reflecting the growing need for holistic development tools. The integration of AI into documentation and planning ties back to what I learned from Bob Ducharme’s blog post on documentation standards, reinforcing the interconnectedness of these areas.

This article expanded my understanding of how AI tools like Copilot are becoming indispensable in software development. I had previously viewed Copilot primarily as a code completion tool, but I now see its potential as a comprehensive assistant for developers, offering support from ideation to deployment. Learning about the integration of Claude 3.5 and Gemini also taught me the value of model diversity in addressing different problem domains. This understanding will guide me in choosing and utilizing similar tools effectively in the future.

In practice, I plan to adopt AI-powered tools like Copilot to streamline my coding process, especially when tackling repetitive tasks or unfamiliar languages. By using AI to augment my development workflow, I can focus more on problem-solving and innovative aspects of programming. Furthermore, as I become more familiar with these tools, I’ll aim to explore their broader capabilities, such as system design support and technical documentation.

Overall, this article is a must-read for anyone interested in how AI is transforming software development. It provides valuable insight into the next generation of development tools, showcasing how GitHub is positioning Copilot as an essential resource for developers. I highly recommend checking it out: GitHub Copilot Moves Beyond OpenAI Models to Support Claude 3.5, Gemini.

From the blog CS@Worcester – CS Journal by Alivia Glynn and used with permission of the author. All other rights reserved by the author.

For my second blog post, I will explore Software Licensing. I chose this topic because we have learned in class about the different types of licensing and what you can or can’t do with specific ones. There are multiple options to choose from when selecting a license for a program or software, and these differences can sometimes be confusing. I decided to dive deeper into this topic and found a blog titled “Understanding Software Licensing” by Fernando Galano.

The blog is divided into five sections: What is a software license? How does it work? Why does it matter? What are the types of software licenses? How do you find the perfect license for your software? The blog does a good job highlighting the importance of a license and the complexities of the legalities that come with terms and conditions. As we learned in class, a license is a type of legal contract between the creator(s) and the users interacting with the software. This interaction for the users can include the installation, modification, copying, or distribution of the software. It’s ultimately up to the creator(s) to select the license they want, which then defines what rights the users possess with the software.

In our class discussions about software licenses in model two, we discuss the different types of licenses and which is the best. The blog also does a good job explaining the differences between them while giving examples of companies that use certain licenses. Some examples of licenses for software are copyleft, public domain, permissive, and open source. Each of these licenses has its benefits and limitations, and it is up to the creator to line up the values they want their software to use. For example, a public domain has no restrictions on how the software can be used, but in comparison, a copyleft license forces derived work to have the same conditions.

The blog ends by explaining why licenses even matter and how to choose which best describes your situation. It explains that licenses have benefits for the user and the creator and these benefits help both parties understand the terms and conditions for its use while avoiding confusion. The author highlights the benefits for the user as an aid to managing tools and resources, clarifying how you can use them, and preventing unnecessary costs for tools the user may not need. The benefits for the creator include preventing unauthorized copying and distribution, limiting liability, and giving the creator control over the usage of their product. What I wish the blog talked about is the similar topic of copyright. We learned about this important topic in part one of software licenses by answering questions like, “You have a new idea for a program, can you copyright that idea?” or “You created a new program based on that idea, is that software copyright-able?”.

This blog did a great job explaining how licenses protect the user and creator while going in-depth on the different types to choose from.

Source: https://www.bairesdev.com/blog/understanding-software-licensing/

From the blog Mike's Byte-sized by mclark141cbd9e67b5 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 clean code. This was one of my favorite topics that we have discussed in class so far.  Even before, I knew that writing good code is important, but I was unsure on how clean code was written. So far I had an idea, from doing exercises, solving problems and writing my own projects either for school or for fun. I thought my code was good enough that it would pass Uncle Bob’s test of clean code, but after reviewing again through his perspective it definitely does not pass as it needs a lot of improvement. Clean code is extremely significant as also stated by the author of the blog, writing code may take up 10% of a programmer’s time while reading and understanding code occupies the remaining 90%. In the blog, the author mentioned how this is even more accurate as in an open-source project like his, where external contributions can be done. The code needs to be clean enough, so the contributors can easily understand and spent most of their time writing code to add to the project. If the code was written poorly, it would make the experience of the contributor a nightmare as he would spend double of his time just reading and understanding, which would leave barely any time to add any new features. If the project goes to be used by multiple users, bugs would eventually pop up and fixing them in a timely manner when the code is a mess it would be very annoying. Even adding new features, it would be extremely time-consuming as you have to do twice the work if the code was written good. This is one of the reasons why I chose this blog from the rest.  The author emphasizes the real problems that come with writing bad code and how much it will cost you time wise to maintain your project up and running. 

Later on the blog, the author points out the importance of functions and formatting. These are two simple things that anyone can learn and apply it to any of their work. 

Some key points that I wrote down for myself were that functions should be kept small and compact. The principle states that small functions increases clarity and reduces clutter. It makes it easy on the eye as it scrolls through the code, knowing what the function does and where it is used in an instance. The second point he mentioned was both vertical and horizontal formatting. He compared it to the Newspaper Metaphor, which it suggested that code should present key information at the top. It is also important to create vertical spaces between different functions which allows separations, and creating a format which is followed throughout the rest of the project. 

Horizontal formatting focuses more on maintaining manageable line lengths. We don’t want the lines of code to be too long, and they should be viewing compatible for every screen size. It is not recommended and always avoided scrolling horizontally in your code as it can become annoying over time and time-consuming. This code in a way was a reflection of my journey towards Clean Code. I had similar mistakes that I did in that past not knowing how to write clean code, but after reading more about it now I am capable of writing clean code. This is a valuable skill that my future self will thank me for mastering!

https://medium.com/codex/reading-clean-code-week-2-643641e4dc28

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

The article “What to Expect From Agile” by Julian Birkinshaw talks about how agile management, which started in software development, is now being used in other industries. It uses ING Bank in the Netherlands as an example to show how agile principles can change a whole organization. ING started its transformation in 2015 to deal with problems like too much bureaucracy and separate departments that didn’t work well together.

Summary

Agile is a method that focuses on being flexible, working together, and improving things little by little. ING decided to use it to make their operations more efficient, inspired by companies like Spotify and Google. They made big changes, like reorganizing their teams into smaller groups called “squads” that handle tasks from start to finish and larger groups called “tribes” that focus on similar goals.

Here are the key things ING learned during this change:

1. Shifting Power: Managers gave up some control to allow teams closer to customers to make decisions. This led to a big culture shift, and some senior managers left because they didn’t fit this new way of working.
2. Keeping Stakeholders Involved: ING worked with regulators and other important groups to show that agile could work while still keeping important rules in place.
3. Focusing on Customers: Teams were organized based on what customers needed and could adapt their focus as those needs changed.
4. Balancing Freedom and Structure: ING used quarterly business reviews to set goals and stay on track while letting teams decide how to get things done.
5. Helping Employees Grow: Agile gave employees more opportunities to learn new skills and take on exciting challenges.

The results were positive: employees felt more engaged, customers were happier, and the bank saved money.

Reflection

What stands out to me the most is how agile balances giving teams freedom while still making sure they’re working toward the company’s goals. It’s not easy to find that balance, especially for industries like banking, where following rules is really important. It also impressed me how ING’s leaders had to let go of control and trust their teams to make decisions. That takes a lot of courage!

As a computer science and business administration student, I see how this case connects both of my fields. Agile started as a software development idea, but it’s now shaping how businesses are managed. If I were in a workplace like this, I’d like having the freedom agile offers, but I’d also want clear support systems to stay on track and make sure we’re meeting goals.

Citation

Birkinshaw, Julian. “What to Expect From Agile.” MIT Sloan Management Review, December 11, 2017.

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