choosing the right software development mythology: Agile, or Waterfall?

Whether you’re embarking on a new project or contemplating a shift in your development approach, deciding between Agile and Waterfall methodologies can be challenging. Selecting the right approach is crucial for the successful development of your project. In this blog, we will analyze the specifics of Agile and Waterfall methodologies to help you make an informed decision tailored to your project’s needs.

Understanding Agile

Ever wondered about the magic behind Agile Software Development? I have recently come across a blog on Agile development by Martin Fowler, a British software developer, author, and international public speaker on software development, who specializes in object-oriented analysis and design, UML, patterns, and agile software development methodologies, including extreme programming. The blog “Agile Software Guide” by Mr. Fowler takes you on a journey through its beginnings and the core ideas that makes Agile work. Written by someone who was there from the start, this blog unravels the secrets of Agile development. The author shares early memories of Extreme Programming and co-authoring the Manifesto for Agile Software Development that sets the stage for an insightful tour through the world of Agile, coming from a credible source who has seen it from its beginnings. The blog dives into the key concepts of Agile thinking, emphasizing how it differs from traditional software engineering. It breaks it down into two main points: being adaptable instead of sticking to plans, and focusing on people rather than processes. A simple breakdown that makes the essence of Agile clear. Mr. Fowler also talks about Agile plans being like a flexible baseline, changing as the project progresses. Unlike traditional plans that demand sticking to a set path, Agile plans are adjusted based on what’s happening. Success in Agile is all about the value the software brings, not just following a rigid plan. However, with all its advantages, the blog doesn’t pretend Agile is perfect. It talks about the challenges, like some practices being called “Agile” when they really aren’t. This honesty adds a dose of reality, reminding everyone to keep an eye on how Agile is actually being used. Agile methodology is often praised for its customer-centric, and flexible approach to software development. In Agile, projects are divided into small increments with minimal planning, and teams work in short cycles, known as iterations or sprints. The methodology emphasizes collaboration, customer feedback, and the flexibility to adapt to changing requirements in which results in continuous delivery of functional software, close collaboration between cross-functional teams, stakeholders, and the customers.

understanding Waterfall

Unlike Agile, the Waterfall methodology follows a linear and step-by-step approach. the project is divided into distinct stages where each stage build’s upon the previous one. The development process flows steadily downwards similar to an actual waterfall, through stages like requirements, design, implementation, testing, deployment, and maintenance. Each stage must be completed before the next one begins, and changes are discouraged once a phase is underway.

How to choose the right methodology? 

The choice depends on several factors, such as project requirements, team expertise, and customer involvement in your development process. If project requirements are clearly defined from the beginning, and changes won’t be necessary during the development process, then the Waterfall methodology could be the right choice for you. However, I personally believe that Agile methodology is usually the right choice for most projects.

In today’s world of constant change, adaptability is crucial in any developmental process. Additionally, based on my experience in various customer service jobs, I’ve realized that customers often don’t know exactly what they want. Therefore, having the ability to adapt if the customers’ needs changes’ slightly is incredibly important.

Agile Software Development: A Concise Overview. (2023). Retrieved from https://martinfowler.com/agile.html

From the blog CS@Worcester – The Bits & Bytes Universe by skarkonan and used with permission of the author. All other rights reserved by the author.

Understanding the Nuances of Smells: Code, Design, and Beyond (Week-11)

In the realm of software development, the term ‘smells’ is often bandied about, yet its nuanced connotations can be elusive. This blog post delves into three distinct types of ‘smells’: everyday smells, code smells, and design smells, exploring their significance and how they metaphorically interrelate with the course material.

My exploration was sparked by an intriguing resource: Martin Fowler’s seminal work, “Refactoring: Improving the Design of Existing Code”. This text, rich in insights, lays the foundation for understanding code and design smells in software engineering. The reason for selecting this resource stems from its practical relevance and the profound impact it has had on my perspective on software quality.

Fowler’s book is a treasure trove of knowledge on how to spot and rectify issues in code (code smells) and software design (design smells). It emphasizes that like an unpleasant odor, these ‘smells’ in software signal deeper problems. The book meticulously categorizes various smells and provides strategies for refactoring, essentially cleaning up the code.

Reflecting on this material, I was struck by the parallels between the tangible world of everyday smells and the abstract domain of software development. Just as an unpleasant smell in a room can indicate something amiss, a code smell suggests underlying problems in the software’s structure. This analogy profoundly altered my understanding of software quality and maintenance.

Code smells, such as duplicate code or excessively long methods, often point to a need for refactoring. Design smells, on the other hand, are more insidious. They indicate deeper issues in the software architecture, like rigidity or needless complexity. Understanding these concepts has armed me with the knowledge to write cleaner, more maintainable code.

Moreover, this resource has reshaped how I approach software development. Recognizing smells early on can prevent costly reworks in the future. It’s akin to addressing a small leak before it becomes a flood. This proactive approach is something I intend to apply rigorously in my future projects.

Application in Future Practice

Armed with this knowledge, I envision a more refined approach to coding and design in my future endeavors. The ability to identify and rectify these smells promptly will not only enhance the quality of my work but also reduce the time and effort required for maintenance.

Conclusion

In sum, the exploration of smells in software, inspired by Fowler’s enlightening work, has been a journey of discovery. It underscores the importance of vigilance and continuous improvement in software development. This learning experience has been transformative, reshaping my approach to coding and design, and it’s a perspective I’m eager to apply in my professional journey.

Sources

Martin Fowler. (2018). “Refactoring: Improving the Design of Existing Code.” Addison-Wesley Professional.

From the blog CS@Worcester – Kadriu's Blog by Arber Kadriu and used with permission of the author. All other rights reserved by the author.

software testing

I’ve been coding since around 2017, when I took my first Computer Science course in high school. Since then, I’ve worked on plenty of school projects and a couple of personal projects as well. Software testing had never been a thing I really bothered with meaningfully in this timespan, which is kind of fair considering that most of these projects and assignments weren’t really too complex. I would just print out results for each bit of code as I went along to make sure that the code I just wrote actually works, but I didn’t really go and write actual automated tests.

This semester, I had some exposure to standardized software testing when I worked on a homework assignment in my Software Design and Construction course that required me to adjust some code along with the tests that make sure the code works as intended with intended output. At first, I was sort of confused considering I had never worked with test files, but I appreciated the streamlined nature of this testing. We also had to read up on some software testing methods for a Scrum developer homework assignment we did for this class, Software Process Management.

Today, I wanted to research some software testing basics, and came across a post on IBM’s blog. The post goes over some reasons to software test (the importance of quality control for businesses, what testing even is, etc.) along with types of software tests and practices.

The different types of software tests are fairly easy to understand, and I’ve come across all of them in some capacity before. Acceptance tests ensure the system as a whole functions as intended, integration tests ensure that software components work as intended, and unit tests ensure the smallest testable snippets work as intended. Performance tests evaluate how well software works on different hardware, and stress tests check how much load the software can take without breaking. Regression tests see if new features harm the software at large, and usability tests evaluate how effective the software is for end-users.

Some good testing practices listed in the article are continuous testing, bug tracking, and service virtualization. Continuous testing is the practice of testing each build as soon as it’s available, fairly simple. Bug tracking is, well, bug tracking. The post mentions automated monitoring tools for tracking defects, but I sort of think of this in the sense of keeping an issues list on a git repository, as that’s what I’m more familiar with. Service virtualization is a little more complicated, it simulates functionality that hasn’t been implemented yet to reduce dependencies and test sooner.

What I’m mostly interested in is the applications of these practices, and I’ll likely look into it further at a later time. I understand these concepts fairly well, but the idea of automating tests, at least at my current understanding of it, sounds a bit daunting. I’m sure it saves a lot of time on larger-scale projects, where testing each piece of your code manually for multiple cases will take a lot of time. I’m interested to see what this looks like in an example.

From the blog CS@Worcester – V's CompSCi Blog by V and used with permission of the author. All other rights reserved by the author.

anti-patterns

During our Software Construction, Design and Architecture class, we’ve gone over a multitude of different design techniques, patterns and tools to ensure that we write quality code. We’ve also touched on some design / code smells and the concept of technical debt. While design smells can give you an indication of something that might be wrong with your code, whether in a small section or in the overall design, anti-patterns represent a much more obvious, prevalent problem in your code.

Some of the most common examples of anti-patterns I’ve heard in conversations I’ve had with my friends, classmates and even teachers in a joking matter, like spaghetti code, and copying and pasting code snippets from random repos (which isn’t just bad practice for coding, it’d also be possible to infringe upon licenses or the lack thereof placed on that code). I think the reason why these are fairly common among the circles I’ve been in is just because everyone has done it before for a school assignment or something, and it’s just funny to joke about.

Some anti-patterns are a bit more involved with designing software in a meaningful sense, though. In a blog post from Lucidchart, some other anti-patterns found in software development and design are golden hammers, god objects, boat anchors and dead code. What’s interesting about these is that they actually are actual manifestations of design smells, in the most obvious ways.

For example, a boat anchor is a piece of code that isn’t being used yet but might be used in a future version, maybe. This results in needless complexity, an addition that isn’t necessary and makes it harder to read your code. Dead code is similar, code that gets executed but isn’t even used in the output of a program, causing immobility. Using a golden hammer means you are using the same tool for a bunch of different jobs, thinking that it is the best tool for all cases. This contributes to fragility, needless repetition and opacity depending on the implementation one goes about with a golden hammer. God objects are similar in a sense, as they’re objects that do too much and are responsible for too many functions. This violates encapsulation principles that are good practice in software design, while also resulting in immobility, viscosity and possibly even more. Dead code

This reinforces the idea of checking for code smells and refactoring code as needed, because otherwise you will build upon a foundation that was fundamentally problematic, and the rest of your code will reflect it no matter how much better it is. This all ties into technical debt, and brings all of the software design principles, concepts and ideas together into a picture that says: please maintain your code cleanly!

From the blog CS@Worcester – V's CompSCi Blog by V and used with permission of the author. All other rights reserved by the author.

The Art of Future-Ready REST API Design

Best practices for REST API design: https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

In today’s digital landscape, REST APIs play a pivotal role in facilitating seamless communication between various clients and services. However, designing these APIs requires careful consideration of factors such as security, performance, and ease of use for consumers. In this blog post, we will delve into the key best practices for designing REST APIs that are not only easy to understand but also future-proof and secure.

Summary: The selected resource outlines essential guidelines for designing REST APIs. It covers crucial aspects like choosing the right data format (JSON), using nouns instead of verbs in endpoint paths, logical nesting for hierarchical objects, handling errors gracefully with standard error codes, and implementing features such as filtering, sorting, and pagination. The article also emphasizes the importance of maintaining good security practices, caching data for improved performance, and versioning APIs to manage changes effectively.

Reason for Selection: This resource was chosen because it directly aligns with the course material, providing a comprehensive guide to REST API design principles. The clarity of the content and its relevance to common challenges in API development makes it a valuable reference for anyone involved in creating robust APIs.

Comments on Content: The guidelines presented in the resource offer practical insights into building effective REST APIs. The emphasis on using JSON for data exchange aligns with industry standards, ensuring compatibility across various technologies. The recommendation to avoid verbs in endpoint paths simplifies API readability and adheres to the RESTful principles of using HTTP methods for actions. The article’s discussion on error handling and status codes enhances the overall robustness of API implementations.

Personal Reflection: As a developer, this resource reinforced the importance of consistency and adherence to best practices in API design. The concept of logical nesting for related resources provides a structured approach that can enhance both API usability and maintainability. Learning about caching strategies and the significance of versioning in API development has broadened my understanding of how to address performance and compatibility concerns in real-world scenarios.

Application in Future Practice: The insights gained from this resource will significantly influence my future API development projects. I plan to implement the recommended practices, especially in areas like error handling, security, and versioning. Additionally, the emphasis on caching strategies will be integrated to optimize data retrieval and enhance the overall performance of the APIs I develop.

In conclusion, the resource serves as a valuable guide for both beginners and experienced developers, offering practical tips for designing REST APIs that stand the test of time. By incorporating these best practices, developers can create APIs that not only meet current requirements but also adapt seamlessly to future changes in technology and user needs.

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

IndependentStudy:GitKitRefactor5

CS@Worcester

Almost at the finish line!

We were able to achieve four to the five steps within the epic. Step 2 and 3 were very closely related and I managed to do them within one step. Creating the ordered list in config.yaml file allowed us to determine the order in which the features are installed rather than depending on the numbers that were prefixedin the indvidual feature files.

The final step, splitting the GitKit repository into KitDeploy and GitKit, is where I am at and it is quite challenging.

I decided to clone the GitKit into my on personal profile by making a repository, KitDeployTrial. KitDeployTrial would contain the eventual file structure that I would have in KitDeploy. After successfully doing this I came across a major roadblock which would not allow me to create new docker images as the pipeline structure had to be setup within the repository.

So I decided to abandon KitDeployTrial and create a new KitDeploy repository within HFOSSedu so that full functionality may be possible with the pipeline. I then moved the necessary files into the repository and the pipeline worked. I then pushed the changes to the GitKit repository but realized that the pipeline was not updating the image in the container repository.

With Professor Stoney’s and Professor Karl’s help I was able to understand how images worked and used the docker pull command to manually update the local image. I was therefore able to update the KitDeploy image locally and begun working on changing deploy.sh

From the blog De Arrow's Webpage by Samuel Njuguna and used with permission of the author. All other rights reserved by the author.

REST API | Week 10

Rest API Designs

In this article the general theme of it helps new or even current programmers understand the fundamentals of REST API’s and help make it more comprehensible as well as to remember important key points in this theme. From how to properly use HTTPS to getting to know how to construct it and remembering what errors you might have, what they mean, this article covers it all. 

I selected this article because sometimes I like to look at things from a different perspective and search around to help me understand something in a different way to clarify a problem or to just maybe help me to connect the dots. Personally this article is a very good introduction into grasping the fundamentals of REST API’s. The material that was observed and taught in class as well as this article really made this click and helped me to move forward with this knowledge in the lessons ahead.  

The article is set up perfectly to go in order of how to design a REST API and why per say the said details are important and it truly helped me to push forward in certain homeworks and as well as the assignments in class. The first operation is to make a simple URL that is simple and just easy. Following up is something that was surprisingly helpful and it was the importance of nouns that you needed to be aware of. This is sometimes being the most common mistake with developers. Tying into that is understanding when to use the right HTTPS methods and why said method should be used as well as why some are more useful than others. Diving to understand and help what parameters are and why we need them. HTTPS methods are just as important as the HTTP codes. Narrowing it down that the most important range of numbers that are used are from 200s all the way to the 500s. Moving to understanding versioning and why it’s very important because it helps keep a check on the amount of updates, small or big that lead to those said versions and helps tracking them when they come out. The last three titles are the use of pagination which helps understand the developer how downloading is going and if its causing any disruptions lowering the services that are in store. API responses must respond or  return in JSON though that may vary if you are using a legacy app. The cherry on top is the using proper error messages. Practice and observe what error messages pull through. 

Link:

https://betterprogramming.pub/restful-api-design-step-by-step-guide-2f2c9f9fcdbf

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

Week 11: CS-343

Software Frameworks

What is a framework?

A framework is a platform providing a foundation for creating software development projects. Frameworks can be thought of as a template of a working program where developers can modify the program by adding code. Because frameworks are essentially templates, there are shared resources that are bundled into one package. Some of these resources include libraries, image files, and reference documents. The package can be customized to match the needs of the project.

Different types of frameworks

Backend Web Frameworks

Backend Web, or also known as simply Web Frameworks, are the most commonly used. These frameworks help developers create web applications and dynamic websites. The use of web frameworks has streamlined the process of web development by automating common tasks of web developers such as database access and session management. Rather than using HTML, JavaScript and CSS, backend frameworks use programming languages to access a database, hosted on a server. A common backend framework is Django.

Frontend

Unlike backend where frameworks are loaded server-side, frontend frameworks are executed in the user’s browser. Frontend frameworks allow developers to customize and design the way the web application looks to the user. Popular frontend frameworks are Angular JS and React.

Mobile Development

Nowadays mobile applications are extremely common resulting in mobile development frameworks. Similarly to desktop frameworks, these give developers a foundation to build their mobile applications while allowing full customizability. There are two types of mobile frameworks, native and cross-platform. Native frameworks are for applications that are built specifically for a particular operating system (iOS or Android). Alternatively cross-platform frameworks are for apps that are built to be compatible with any phone. A commonly used mobile framework is Flutter.

What makes a good framework?

A good framework should be simple to understand and easy to implement. It should also follow design principles such as:

  • Being extendable, adding new functionality by adding code rather than modifying
    • Framework cannot be modified at all, but only extended
  • Allows developers to create components that can be reused
  • Should have a default behavior and be useful. No redundant code that is unnecessary

Why use a framework?

Frameworks greatly reduces the time spent on developing. When starting a new project, there are steps that need to be done regardless the project. Using frameworks helps streamline that process by already providing those details. This allows developers to focus their time on extending the functionality specific to their application’s needs.

Reflection

This article was chosen because it broke down the different parts of a framework such as what it is, the different types, and why one might use a framework. Prior to reading this blog, I had a somewhat unclear understanding of what frameworks are. Now I understand that they are useful tools that speeds up the development process by providing essentially a template of a working program. What was learned will be applied to future, larger projects that could benefit from a framework.

Resources:

https://codeinstitute.net/global/blog/what-is-a-framework/

From the blog CS@Worcester – Zack's CS Blog by ztram1 and used with permission of the author. All other rights reserved by the author.

copyright licenses

We’ve covered software licenses a fair amount in our Software Process Management course. The MIT license, Apache License, and GNU GPL were the most notable for different reasons, but I figure that there are far more licenses that we haven’t necessarily gone over directly in class. I wanted to take the time to familiarize myself with some of these licenses.

Starting off with a CopyLeft license (a type of license I find myself fairly sympathetic to for the sake of keeping software open source), the Mozilla Public License, or MPL, is a weak sort of CopyLeft. According to this post on fossa.org, this means that users must disclose changes, but for a much narrower set of code for each change, file-based for short. When compared to the LGPL, a notable weak copyleft license, the MPL allows users to sublicense as an additional permission. Notable uses of this license are, of course, Firefox and Thunderbird, along with LibreOffice. I do like the idea of having a middle ground between being completely permissive and also wanting to “spread” open-source.

BSD Licenses are permissive licenses that generally have no restrictions. This license seems to fall in line with the big permissive licenses (like MIT) and doesn’t have a viral effect, but requires a copy of the license and a disclaimer of liability. According to a post on AppMaster, the differences between the MIT licenses and the BSD licenses is there being no requirement for a liability disclaimer for the MIT license, no requirement for patent protection on the BSD license, the BSD license being compatible with GPL, and the MIT license requiring a permission notice. I don’t like the lack of patent protection with this one, I know that’s been a fairly annoying issue in the past for various projects.

Lastly, I took a look into the OpenSSL license, as it was on the front page of tldrLegal. Funnily enough, it’s a license styled off of the BSD license, with the express purpose of being used with the OpenSSL project. On the aforementioned tldrLegal page for the license, it mentions in the summary that the license has a special advertising clause, which means that ads mentioning the software in any way must acknowledge the use of OpenSSL. The takeaway, for me, is that if you know exactly what you need with your license, and one that exists has everything you’d like except for one specific requirement or permission, you can build off of that license with that added requirement or permission (assuming that you have a legal expert of some sort write it, I’m assuming).

Overall, I really appreciate the work that has been done to ensure that we have a variety of different ways to license our software depending on what we want done with it. It’s definitely an important aspect of open-source development, and having the resources to find licenses that are closest to the project’s vision is an excellent way to focus on the development and not have to worry about the legal stuff.

From the blog CS@Worcester – V's CompSCi Blog by V and used with permission of the author. All other rights reserved by the author.

Git and Game Development

     A subject that has always been near and dear to my heart is video games. Throughout my life I have always been deeply enamored with games and the process of their creation, from the intricacies of 3d modeling to the various game engines in use. Despite that, I would not say I am an expert in modern game development by any means. As my classes have progressed however, I have begun to understand more about the inner workings of software development and how teams are managed. This led me to investigate how game developers use these tools to manage projects and keep everything orderly. After doing some research, I found that many game engines are compatible with git and have no issue being stored on GitHub. Not only that but prominent game engines like Unreal Engine even have their source code up on GitHub, available for anyone to fork and clone. This was done to allow developers to modify the game engine itself, for whatever purposes they need. Godot is a free open-source engine that uses the MIT license and is also entirely up on GitHub. Of course, even if an engine does not have their code on GitHub or Gitlab that does not mean you cannot just host your code in an online repository. Thanks to what I have learned this semester, I can now make use of GitHub in the creation of repositories for any game projects I have. 

  It is not enough to learn about how game developers make use of git, project management is also a vital tool for game development. In terms of project frameworks, agile methodologies have seen widespread use within various industries, including the video game industry. Scrum is the most prominent of these methodologies and has been adopted by various companies. Due to the nature of video game development, there is a greater need for cross-disciplined teams comprised of developers versed in various skills. Game development can be effectively chopped up into tasks that fit nicely into each increment, for the medium itself necessitates a functioning step by step pipeline. Level designers cannot do anything without the assets created by artists and so on and so forth. The first couple sprints would work on creating functional assets like 3D models, textures, and game mechanics. The goal of each subsequent sprint would be to create a functional game section by section. I hope to one day make use of scrum and help create a game of my own.

https://www.unrealengine.com/en-US/ue-on-github

https://www.gamedeveloper.com/production/agile-game-development-with-scrum-teams

https://starloopstudios.com/best-agile-practices-in-game-development/

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