Category Archives: Software Development

How Much Formatting is Too Much?

https://www.steveonstuff.com/2022/02/09/nitpicky-code-reviews-are-are-drag

This post from Steve Barnegren discusses his issues with the current state of team code review. Specifically, the blog takes time to point out the issues with being overly obsessive about nice formatting. It is one thing to point out flaws in logic and potential failures the system may have, giving feedback on how it might be improved or fixed, and another to, for example, say a ternary operator should be used instead of an if-else. The argument is made that a majority of ‘formatting issues’ of the variety I’ve given do not give enough value for the time they take between maintainers and developers.

Personally speaking, I like to have my code in a very consistent format. If just one thing is in a different format, it seriously bothers me. It wasn’t until recently when I started working on a project as a member of WSU’s Computer Science Club that I personally had to work in a team larger than two people, and in doing so I found out pretty quickly that many people do not hold the same standards to their code.

One team member very specifically does not care at all about how the code is formatted, focusing solely on efficiency and output. At the beginning of the project, I gave pushback on this, believing that the code he was writing was very poor if we wanted to maintain standards, but I was assured it wasn’t a big deal. All of us were working on different parts of the project and generally were disconnected from one another until it came time to connect things. I specifically was on my own creating the GUI of the project. However, the issue finally came when it was time for me to start working on the backend. What I found was a disaster, not in terms of functionality necessarily; there were definitely errors in output, but that wasn’t my concern. The real disaster was the cleanliness of the code. Trying to figure out what was going on, how things were calculated, what and where things were stored, it was a lot of tracing. 

By the time I finally understood what was going on, it took me very little time to do what was asked of me, but the process to get there should not have taken that long. The person who originally wrote the backend is now working to create extensive documentation so that way people don’t have to go through that process again. If there had been consistency in the formatting of the code, clear demonstration of how things functioned, and precautions taken to make sure things did not get out of hand, I feel it wouldn’t have been nearly as bad. 

Although I hear this blog’s thoughts, I hear them echoed in the person who originally said it wasn’t a big deal. In my opinion, the condition for a team to have code reviews like the one Steve recommends must be that all team members already agreed and showed the capability to write code that is clean and makes sense, or else you get the horror I had to go through. Generally, I think code reviews should be unique to every team, because the same rules don’t work for everybody, and that the nitpicks have their place in teams.

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

Code Review

Source: https://about.gitlab.com/topics/version-control/what-is-code-review/

This article is titled “What is a code review?” As clearly stated by the title, the article explains the processes of code reviewing. “A code review is a peer review of code that helps developers ensure or improve the code quality before they merge and ship it.” Code reviews help in the identification of bugs, increase the overall quality of code, and enhance understanding of the source code. Code review, as suggested in the name, happens after a software developer has finished coding. Code needs to be checked before it is merged into an upstream branch for bugs or conflicts. A code reviewer “can be from any team or group as long as they’re a domain expert. If the lines of code cover more than one domain, two experts should review the code.” Adhering to a solid code review process allows for continuous improvement of code and aims to ensure that faulty code isn’t being implemented for customers/users to see and use. This process isn’t just important for the code itself, but also for all of the team members of a software development project. Whilst reviewing the code, meaningful knowledge of the source code is shared between team members to ensure that it is being implemented properly. The main benefits of the code review process are: the sharing of knowledge, discovering bugs earlier, maintaining compliance, enhancing security, increasing collaboration, and improving code quality. Code reviews allow for maintaining compliance because different developers have different backgrounds and thus different personal processes when they are developing. Code reviews allow these people to get together and maintain a standard coding style. Security is enhanced because “security team members can review code for vulnerabilities and alert developers to the threat. Code reviews are a great complement to automated scans and tests that detect security vulnerabilities.” There are many benefits to code review, but there are some disadvantages, including: longer time to ship, focuses being pulled from other tasks, and large reviews mean longer review times. These can be described as necessary evils due to the sheer amount of positives that code reviews offer in software development.

I chose this article because it was published by GitLab, a software that we are heavily using in class for version control, and I thought that it would be interesting to read this specific topic from the syllabus. Version control softwares such as GitLab allow code reviews to happen, so diving deeper into the topic in an article published by this popular software company was tempting. Before reading this article I understood that code reviews were important to pinpoint any bugs or difficulties before merging code into the upstream, but I never really thought about the implications of security or different development styles. I’ll definitely keep this information in mind during future code reviews on the job to remind myself that bugs aren’t the only important thing during a code review.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

YAGNI

Source: https://www.geeksforgeeks.org/what-is-yagni-principle-you-arent-gonna-need-it/

This article is titled “What is YAGNI principle (You Aren’t Gonna Need IT)?” YAGNI is “a principle in software development that suggests developers should only implement features that are necessary for the current requirements and not add any additional functionality that might be needed in the future.” The reasoning for this is that if you add features that might potentially be needed in the future, there will be risk for more bugs, increased complexity, and increased times of development, thus leading to increased cost. The YAGNI principle is similar to the KISS principle (Keep It Simple, Stupid), which also advocates for simplicity, it encourages developers to avoid complexity when it isn’t necessary. Developers should follow the YAGNI principle if they wish to keep the following costs in mind: the cost of building, delay, carry, and repair. The cost of building refers to the total cost of efforts and resources implemented in the project. Building things that aren’t needed leads to increased costs overall. Cost of delay refers to missed opportunities, if you spend time on unnecessary features, the development of more important ones will inevitably be delayed. Cost of carry refers to the difficulties of having unnecessary complex features. These complexities make it difficult to work on other parts of a software project, require more time, lead to an increased cost, and overall cause harder times moving forward. Lastly, the cost of repair, or technical debt, refers to the costs associated with bugs or mistakes that occur during the development process. YAGNI is important to ensure that the development process is focused, efficient, and cost-effective. YAGNI can be implemented into your code by prioritizing communication between team members. Ensuring that necessary requirements are met, a simple plan is made, ignoring ideas that don’t meet goals or deadlines, and keeping good records of project progress will allow your team to follow the YAGNI principle. YAGNI allows for simplicity, faster development, flexibility, reduced risk, and cost savings by complementing other development principles while prioritizing unnecessary implementations.

I chose this article because I appreciate how geeksforgeeks simplifies topics within the software development community. I don’t recall this principle being explicitly mentioned in class, but we have definitely alluded to it and I thought it’d be beneficial to read about it more, considering that it is in the syllabus. It was interesting to learn that the YAGNI principle complements other software development principles, such as the KISS principle, and compiles them into a unique principle that prioritizes simplicity over complexity and more features. It embodies the idea of “less is more.” This is a great set of guidelines I’ll be sure to follow in industry because it promotes that sometimes less work isn’t a bad thing. Instead of creating a multitude of features, ensuring that the ones that are critical, and required sooner, are being developed, will still get the job done.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

A Microservice

A General Dive

This week, I looked into the topic of something called microservice architecture. It’s a way of designing software systems that breaks them into smaller, independent services that work together. To better understand it, I read the article “MicroserviceArchitecture”, which gave me a beginner-friendly explanation of how it works, its benefits, and some challenges. Since I’m new to computer science, I thought this topic was interesting because it seems like something I might use if I ever work on big software projects.

The article explains that instead of building one big application (a monolith), microservices split the application into smaller pieces. Each piece, or “service,” can do a specific job, like managing user accounts or processing payments. These services talk to each other using APIs, and they’re independent, so you can change or fix one without messing up the others. The article also talks about the pros and cons. On the good side, microservices make apps easier to scale and maintain. But on the downside, they can get pretty complicated to set up and manage.

I picked this article because microservices came up during class discussions, and I didn’t really get it at first. I wanted to find a resource that explained the basics without assuming too much prior knowledge. This article seemed perfect for a beginner because it explains things step by step. I also chose it because I’ve always wondered how big companies like Netflix or Amazon manage their systems, and it turns out they use microservices.

The biggest thing I learned is how microservices make scaling easier. For example, if one part of an app is getting more traffic—like a checkout service for an online store—you can scale just that service without touching the rest of the app. I thought that was really cool because it makes so much sense for big companies. Another thing I learned is how microservices make it easier for teams to work on different parts of a project at the same time. On the flip side, I also realized that microservices can be tricky because you have to make sure all the services work together smoothly. This made me think about how important it is to plan ahead when designing software.

I think this knowledge will be useful later when I work on group projects. If we ever build something complex, I might suggest using microservices to keep things organized. I also want to learn more about tools like Docker, which the article mentioned, because they help manage microservices.

Resource:

microservices-architecture

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.

AI Is Not A Software Engineer

In this blog, the author discusses how much the times have changed for new CS graduates. Reminiscing about how little they knew and how easily they got a job. Then talks about how much more prerequisite knowledge is needed to even sniff a job. The topic of the article is how now more than ever it is easier to get code that works. Thanks to AI, code is now more plentiful than it ever was before. However, all code is not good code. This leads to them discussing how despite how much code there is these days. Having people capable of understanding and able to build software are still very necessary. 

Although AI can now code for us, the coding wasn’t the hard part in the first place. The hard part was building software, and making good software. It’s easy to throw a bunch of code snippets together that accomplish something. But it is something entirely different to build specialized software that fills certain functions and meets certain criteria. AI cannot replace people, even though it may take away some jobs. At its heart, AI cannot build unique software. Teams of capable developers are still needed. The nature of how people code is changing. It’s becoming more important to be able to harness AI, but still oversee and build functional software.

I chose this article because I think it relates to team building. Like the article said, you need people who can understand code, not so much write it. Writing code is easier than ever, but finding people who understand how to build software is harder than ever. When using these tools it’s important not to rely on them too much. Discerning who can actually code these days is probably one of the most important skills for employers these days.  I think it’s important for me and everyone to keep in mind that AI is a tool. Tools dont make up for lack of knowledge. Tools are used best by people who know how to use them and maximize their use. One tool can’t solve every single problem. At the end of the day, knowledge is the most important part of being a software developer. 

Citations

https://stackoverflow.blog/2024/06/10/generative-ai-is-not-going-to-build-your-engineering-team-for-you/

By Charity Majors

From the blog CS@Worcester – Code Craft by Kyle Tucker and used with permission of the author. All other rights reserved by the author.

Understanding UML: A Simple Guide to the Unified Modeling Language

In 1997, the Object Management Group (OMG) introduced the Unified Modeling Language (UML). It was created to help IT professionals design and communicate software systems more easily. Think of it like blueprints for a building UML gives developers a standard way to plan and share their ideas about how a system should work.

UML has become a popular tool in the tech world. You’ll often see it listed on resumes, but many people don’t actually know how to use it well. That’s why learning the basics of UML is important if you want to include it in your skillset. In this guide, we’ll cover the article written by Donald Bell who works as a solutions architect for IBM, and some of the most common diagrams and how they’re used.

What Makes UML Special?

UML is not tied to a specific programming language. This makes it flexible and easy to use in many different environments, whether you’re working with Java, .NET, or something else. Also, UML is a language, not a method. This means it can fit into any company’s way of working without requiring big changes.

The main purpose of UML is to help teams understand and share their ideas more clearly. By using UML diagrams, teams can communicate how a system will work, making it easier for new members to join a project and get up to speed quickly.

Key Types of UML Diagrams

Use-Case Diagrams: These show how users (called “actors”) interact with the system. For example, they can illustrate how a customer logs into an app or makes a purchase. Use-case diagrams are simple and focus on the system’s main functions.

Activity Diagrams: These diagrams show the flow of actions in a process. They’re great for mapping out workflows, like how a customer service ticket moves from “open” to “resolved.” Activity diagrams are easy to understand, even for people who don’t have a technical background.

Deployment Diagrams: These focus on where parts of the system will run, like servers or applications. They show how different pieces of the system communicate and help teams plan how everything will work in real life.

Why UML Still Matters

UML has been around for over 25 years, but it’s still widely used because its core ideas are timeless. Much like classic software books that are still relevant today, UML helps solve problems that developers face every day.

Even without fancy tools, you can start using UML with just a whiteboard or pen and paper. By practicing with basic diagrams, you’ll improve how you share your ideas and work with others on software projects. Keep learning, and UML can become one of your most useful tools!

Reference

https://developer.ibm.com/articles/an-introduction-to-uml/

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.

Masters in Scrum

One method I’ve encountered repeatedly in both my coursework and during discussions with peers is Agile—specifically, the Scrum framework. To better understand it, I recently read an article titled “Scrum Mastering the 3 Pillars, 5 Values, and 7 Key Principles of Agile Project Management”, which provides a clear breakdown of how Scrum works and why it’s so effective in software development. I found this resource insightful, and it’s something I can definitely apply in my future

The article explains the fundamental elements of Scrum, which include the 3 Pillars, 5 Values, and 7 Key Principles that form the foundation of this Agile framework. The 3 Pillars—Transparency, Inspection, and Adaptation—ensure that the process is open, regularly assessed, and flexible. The 5 Values—Commitment, Courage, Focus, Openness, and Respect—help create a collaborative and supportive team environment. Finally, the 7 Key Principles emphasize continuous improvement, self-organizing teams, and the importance of simplicity in problem-solving.

I selected this article because, as a beginner in computer science, I wanted to understand how project management frameworks like Scrum can be applied in real-world software development. Being new to coding and programming, I often feel overwhelmed by the amount of information and tools available. Scrum, with its structured approach, offers a clear way of organizing tasks, fostering teamwork, and ensuring that progress is continually monitored. Learning about Scrum is relevant to my future career because it’s widely used in the tech industry, particularly for software development and managing complex projects.

From reading the article, I gained a solid understanding of the core principles that make Scrum effective. The 3 pillars stood out to me, especially Transparency. As a student, I can relate to the importance of transparency in team projects where communication is key to understanding who’s doing what, when, and how. Inspection and Adaptation also made me realize how crucial it is to frequently check our progress and be willing to change course when necessary, which can save a lot of time and effort in the long run.

The 5 Values were a reminder of the importance of collaboration and maintaining a positive, respectful team environment. These values are essential, not just for Scrum but for any professional setting. I particularly appreciated the focus on Courage, which resonated with me as I’m still learning how to approach new and challenging problems in my coursework.

Finally, the 7 Key Principles reinforced the idea of simplicity and the need to avoid overcomplicating solutions, something I’ve noticed in my own work when I get caught up in trying to build complex solutions rather than focusing on what’s truly necessary.

I plan to apply the principles of Scrum, especially the importance of adaptation and simplicity, in my future projects. Whether it’s a group coding project or individual work, Scrum’s emphasis on regular inspection and continuous improvement will help me ensure that I’m always learning and adjusting as I go.

Resource:

“Scrum Mastering the 3 Pillars, 5 Values, and 7 Key Principles of Agile Project Management”

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.

Software Maintenance

Source: https://www.geeksforgeeks.org/software-engineering-software-maintenance/

This article is titled “Software Maintenance – Software Engineering.” Software maintenance “refers to the process of modifying and updating a software system after it has been delivered to the customer.” There are many different aspects involved in this including: fixing bugs, adding new features, and keeping up with new hardware and software requirements. Maintenance is very important for ensuring that software is able to last long. This process can be expensive and complex, so these factors must be taken into account during the planning of a software development project. The important tasks in regard to software maintenance are: bug fixing, enhancements, performance optimization, porting and migration, re-engineering, and documentation. Summarizing these tasks, it is important to find and fix errors quickly, add new features/improve existing ones, improve the performance of the software, adapt the software to run on different hardware, improve the design, and maintain accurate documentation of all of these processes. There are quite a few different types of software maintenance, but they can be categorized into proactive and reactive types. “Proactive maintenance involves taking preventive measures to avoid problems from occurring, while reactive maintenance involves addressing problems that have already occurred.” Maintenance can be done by stakeholders, the development team, a third-party, and they can be both planned or unplanned. Planned maintenance can be described as regular maintenance (bug fixes) while unplanned maintenance can be described as reactive maintenance that occurs when something unexpected happens. Maintenance can fall into these different categories: corrective maintenance, adaptive maintenance,  perfective maintenance, and preventive maintenance. Corrective refers to fixing bugs and enhancing performance of the system. Adaptive refers to modifications being made when a customer needs the software to run on a different system. Perfective refers to the adaption of the software when a customer has a demand. Lastly, preventive maintenance refers to modifications that focus on the prevention of future issues with the software. Software maintenance is important but there are some things to consider: the cost, complexity, possibility of new bugs, users not updating the software, compatibility, technical debt, and end-of-life (where maintenance isn’t possible anymore or cost-effective).

I chose this article because I found it in the syllabus and thought the topic to be interesting. We are always learning about the development of software, but the idea of maintaining it over the long term isn’t as heavily considered. A large part of the work of a software development team is to obviously develop software but it is also important to learn about how it can maintain a sense of longevity free from error and customer complaints. I will keep the information I learned from this article in mind in future projects and when I’m working with a team to ensure that I’m developing software all the while keeping maintenance in mind. If it is considered during the development process, the maintenance process will be much easier.

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

Introduction to Pattern Designing

Source: https://www.geeksforgeeks.org/introduction-to-pattern-designing/

This article is titled “Introduction to Pattern Designing.” In regards to software development, “pattern designing refers to the application of design patterns, which are reusable and proven solutions to common problems encountered during the design and implementation of software systems.” These reusable design patterns showcase relationships that occur between classes or objects. They are language dependent, so they can be described as an idea that makes code flexible and overall speeds up the process of development. Their purpose is to solve common problems. There are three main kinds of design patterns, creational, structural, and behavioral. “Creational design patterns abstract the instantiation process.” Creational design patterns offer a sense of flexibility in regards to “what gets created, who creates it, how it gets created, and, when.” Knowledge about which concrete class is being used is encapsulated and the way instances of classes are created is hidden. “Structural design patterns are concerned with how classes and objects are composed to form larger structures.” Inheritance is used to create interfaces/implementations. Structural design patterns are good for when you want to make independent class libraries collaborate effectively with one another and offer flexibility regarding object composition. “Behavioral design patterns are concerned with algorithms and the assignment of responsibilities between objects.” Patterns of communication are being described here. Inheritance is used to divide behaviors between classes, object composition is used for behavioral object patterns, and the object patterns encapsulate behaviors in objects. Overall, the benefits of pattern designing are reusable solutions, scalability, and abstraction/communication. The downfall of it however is that there is a learning curve while you try to understand the patterns, there may be concerns with when you should apply the patterns in your code, and if patterns aren’t implemented consistently and in correlation with the advancement of the system, maintenance issues may occur. But regardless, they are a great way to solve common problems during the development process.

I chose this topic because the idea of design patterns was in the syllabus and it interested me. We learned about design patterns such as Factory, Strategy, and Singleton, but reading about the larger terms of creational, structural, and behavioral patterns offered deep insight into the topic. The supposed benefits of common methodologies in software development are always presented but it is also good to know about the downfalls, which I am glad this article showed about the design patterns. When I am working on a team or in the workforce, I will definitely reference these design patterns to improve the maintenance capability and scalability of my code, and do so in a way which I am able to avoid the downfalls of implementing them incorrectly. 

From the blog CS@Worcester – Shawn In Tech by Shawn Budzinski and used with permission of the author. All other rights reserved by the author.

To Be Agile

I recently came across a blog post on LucidSpark titled What Is Agile Methodology? that explains the basics of Agile and its role in modern software development. Agile is a project management and software development approach that emphasizes flexibility, collaboration, and customer feedback. The methodology breaks down large projects into smaller, manageable chunks called sprints—usually lasting a few weeks. This approach allows teams to adapt quickly to changes, make continuous improvements, and deliver working software regularly. The blog goes on to explain the Agile Manifesto, which highlights values like individuals and interactions over processes and tools, and customer collaboration over contract negotiation.

I chose this article because it offers a clear, easy-to-understand explanation of Agile, a methodology that I’ve heard about a lot in my software engineering classes and in discussions about software projects. I wanted to learn more about it and see how it’s used in real-world development, especially since I might be using it in some of my future group projects. The post helped clarify some of the concepts I’ve learned in theory and gave me a better understanding of how Agile works in practice.

One of the most interesting takeaways from this article was the emphasis on adaptability. In traditional project management, there’s often a lot of upfront planning, but Agile is all about being able to adjust quickly to changes—whether that’s changes in customer requirements or new technologies. I realized that in software development, the ability to pivot and change direction is just as important as having a solid plan in the first place. This idea of “failing fast” and improving iteratively really resonated with me. I’ve noticed that when I work on assignments or personal projects, sometimes things don’t go as planned, and it’s frustrating to try and stick to a rigid approach. Agile’s flexibility seems like a better way to handle those situations.

Another part of the article that stood out was the focus on collaboration. Agile teams work closely together and communicate regularly, which is different from the more isolated approach I’ve seen in some projects where team members work separately and only come together at milestones. The post explained how frequent communication, daily stand-ups, and collaboration with customers can help create better products and avoid misunderstandings. This is something I want to keep in mind for group projects, especially in coding assignments where communication can make a huge difference in the quality of the work.

In my future career, I plan to apply what I’ve learned by adopting some Agile practices in my own projects. I want to be able emphasize collaboration and open communication in group assignments, which could lead to more efficient and effective teamwork.

Resource:

https://lucidspark.com/blog/what-is-agile-methodology

From the blog Computer Science From a Basketball Fan by Brandon Njuguna and used with permission of the author. All other rights reserved by the author.