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.

https://www.blackduck.com/blog/generative-ai-risks-in-software.html

This blog posts discusses the issues that AI generated code causes for licensing caused by the use of proprietary code in model training, and issues for coding standards caused by the varying quality of AI code. I chose to look at this blog because I know many of my peers, including myself, occasional use AI to generate code for debugging and for small chunks of code that they don’t feel like making on their own for the sake of efficiency. Even in these small cases, we run the risks proposed by the blog.
Reading this blog made me reflect on how I use AI in my own coding, especially as it relates to coding standards. Typically I use it for debugging, which really means the only thing I need to concern myself with is making sure I understand the adjusted code and it follows the same formatting I used. However, this has affected my thoughts about using AI for small snippets that would be more efficiently written with AI. Upon reflection with the article, it made me realize the reason we allow AI to write code, is the same reasons we always write bad code; we just want to get it done. The most interesting part is, it also has the same consequences as just rushing to get it done. There have been a handful of times when I’ve been looking at a peer’s code, and it did something I thought was quite impressive, then I went to ask them about the functionality of it, but they were unable to do the fact that they were not the ones who actually wrote the code I was interested in, and it was so abstracted that they themselves did not really understand it.
I will admit I’ve had similar things happen before. For example, there was one time when I was working on a project, and there was a method I had to write that was very annoying. So I asked an AI to write it for me so I could move on with my project unannoyed. The code it wrote functioned in the tests I gave it, and it was even formatted correctly, it also had comments that describe what it was doing. Later on in the project I was getting very ludicrous results, and I had no idea why. After a while, I went back to the code and realized, the comments it wrote basically just recited the prompt I gave it, and did not actually describe what it was doing. After making attempts at fixing it, I ultimately had to completely rewrite the method on my own, wasting much of my time. My experiences as well as this article have allowed me to realize just how important writing clean, and understandable code is, and why we should avoid trying to cut corners on our projects even if it seemingly save us time. It is far more important to make good code at an efficient, than generate functioning code at a fast pace.

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