Hello, and today’s blog post is about Scrum. For those of you who do not know, Scrum is basically a way to work as a team efficiently and effectively. I am glad that Professor Wurst chose to expose us to Scrum in his curriculum this semester because this method of teamwork is very interesting, and it actually seems like it could be useful to me in the future. The thing I really like about Scrum is that it is INCREDIBLY organized. Each day is planned out to an hour, and I think that having a schedule that is organized and efficient is very important when you actually want to get work done. Planning out your schedule/agenda ahead of time ensures that everyone on the team stays on track with minimal distractions. This method also is all about improvement. There are reflections/retrospectives at the end of every sprint (which is pretty much another way to say “project”). We went over this in detail during our class time, which engraved a lot of the Scrum knowledge in our heads. We also took official quizzes which helped us become “certified.” I think taking these Scrum tests were beneficial because we had to reach a certain score, and if we didn’t get it, we would have to re-do the tests until we had a much better understanding of the concepts.

Scrum uses the Agile framework, which I talked more about in one of my previous blogs. Scrum is based off of three pillars: transparency, inspection, and adaptation. The official Scrum website described the process of working using Scrum as “working through small experiments, learning from that work and adapting both what you are doing and how you are doing it as needed.” Scrum also has important values: courage, focus, commitment, respect, and openness. These values are each crucial to making this process work.

The article I chose to help me explain Scrum for this blog is linked here: An Introduction to Scrum | Lucidspark

This article describes Scrum as “an iterative, adaptable approach to software development.” It talks about how most software development methodologies are very linear, meaning there is not much room for improvement. Scrum on the other hand, as I mentioned before, follows the Agile approach rather than the Waterfall methodology, which makes for great adaptability. The article also re-iterates how Scrum is all about teamwork and collaboration. It goes into detail about each role in the Scrum team, and what all the events are in the sprints. I think this article is worth a read, and it is supposed to be just an 8-minute read as well.

Overall, Scrum is definitely one of the best software development methodologies that are in sync with Agile ideologies, so I am glad that we learnt about it!

From the blog cs@worcester – Akshay's Blog by Akshay Ganesh and used with permission of the author. All other rights reserved by the author.

Hello WSU blog! In this post I am going to talk about what I learnt in class in regards to software licenses. We watched an informative video on it in class, and then we worked in groups to practice with the information from the video. I actually learnt a lot of simple things about copyright that I never noticed until this class. One thing I learnt was that there is actually an automatic copyright for things that you don’t license. This means that if you want someone to be able to legally use your code, you HAVE to license it, and pick the permissions that they have to use your code. When you license your code, you do not in fact give up your copyright. The copyright will always belong to you, however licensing it lets other people use your code in certain ways.

In this activity we also compared two different licenses. We compared the MIT License, and the GNU General Public License. The MIT License is simple and permissive, meaning that it allows the users of the code to do more things with it. On the other hand, the GNU General Public License has a few more conditions, such as disclose source, same license, and state changes. An extra permission for the GNU license is Patent use. We also briefly looked into non-software licenses as well.

The blog post I researched for this week’s blog is linked here: What is a Software Copyright?

I chose this blog to research because it was pretty simple and easy to understand, while also being very informative. This article mentioned HOW exactly your software is protected due to copyright licenses. It talked about points we covered in class, such as the automatic copyright, which is put into play as soon as the software “is created and saved in some way.” The way the software is written is protected by copyright law, and the owners of the software can give other people access/permission to use their code with the use of licenses. The article also concluded by emphasizing the importance of software licensing and how essential it is for people who want to create or use shared software.

Overall, I think that learning about this stuff while we are still in college is important, and I am glad my professor took the time to include this in the content of this course. Copyright and Licensing is important, and it prepares us a little bit more for the future and real-world applications.

From the blog cs@worcester – Akshay's Blog by Akshay Ganesh and used with permission of the author. All other rights reserved by the author.

Hello, this is my second topic-based blog and today I will be talking about something I learnt about in depth over several days in my Software Process Management class. This was a very interesting topic and I learned a lot of things about code that I had previously not known about. Some of the things that I was taught in my earlier days of coding were proven to not be the best way to go about making organized, clear code. One example of this is that I was originally taught to make comments after most lines of code, just to make sure everyone reading the code will understand it. However, it turns out this was just a beginner step to help myself learn. In reality, clean code should be easy to read and understand, making many comments obsolete.

Now I will talk about some examples of obsolete comments. One of these are redundant comments. These are comments that are unnecessary. An example of this would be: z = x + y (sets z to the sum of x and y). As you can see, the code speaks for itself, and this comment is completely obsolete. Another comment type that is unnecessary would be misleading comments. These comments are usually created when someone forgets about a comment after updating the code. This leads to the wrong comment being on a block of code that doesn’t even do what that comment states!

The blog I researched for this post is linked here: Writing Clean Code: Tips and Best Practices – DEV Community

Unsurprisingly, this blog shared many of the same values that I learnt about in class. It gave me an overview of the material I had gotten an in-depth understanding of, with many additional helpful tips and tricks. This blog mentioned using meaningful names for your classes, functions, methods, and variables. This ensures that someone else who is reading your code can easily understand EXACTLY what everything is used for. Ex) “bananas VS. bananasInBasket”

Another thing that this blog shared with what I learnt about is to make sure functions and methods are small and limited to a specific number of lines. You don’t want an entire code that may be repeated inside one method. Instead, create a function that you can call inside the method to keep the code clean.

The website also mentioned good practices for making comments, and to make sure you refactor your code a lot over time!

From the blog cs@worcester – Akshay's Blog by Akshay Ganesh and used with permission of the author. All other rights reserved by the author.

Hello, this is my second blog post. Today I wanted to talk about something I learnt about in my Software Process Management class. The topic of this blog is two methodologies in software development; the waterfall method, and the Agile method.

For those who do not know, the waterfall method is a very “set-in-stone” methodology, where each part of the software development process is pre-determined with deadlines and time constraints. Something I dislike about this methodology is the lack of communication between the company and the people creating software for them. I think it is very important to have a strong connection during the whole process, not just the start and the end. The Agile method is more flexible. There are pre-determined steps, just like in the waterfall method, however, they are conducted in much shorter time intervals and repeated several times. This allows more communication between customers and developers.

In my opinion, both methodologies have their own uses, which is something we talked about during a class discussion. We were asked to speak about which methodology would be better in different situations. I think that for a large-scale community/government project (such as building a bridge), the waterfall method could be useful since a lot of communication is not needed with a certain customer. For projects where the developers are creating an app/product for a company, I think Agile outshines the waterfall methodology by far, due to the reasons listen in the above paragraph.

I also used this website to learn a bit more about both methodologies: Agile vs. waterfall project management | Atlassian

This website reinforced my ideas and outlook on both methodologies. It highlighted that in the waterfall method, you are unable to move forward without completely fulfilling the first “phase.” It also went into detail on how in the Agile methodology is more flexible than the waterfall methodology. The waterfall methodology is much less able to be changed in any way, and it is a very linear methodology. There are also some helpful images on this website which I would recommend checking out to visualize both methods!

From the blog cs@worcester – Akshay's Blog by Akshay Ganesh and used with permission of the author. All other rights reserved by the author.