Category Archives: CS-348

On the subject of Output-Oriented Software Design…

This week, I am going to discuss some of the benefits of the output-oriented software development methodologies we have been studying in class, like Scrum and Agile. I have built many projects both on my own and for my career from the ground up, which is where the value of these methodologies is most apparent to me. The blog post I will be referencing throughout this discussion can be found here. This post provides an in-depth overview of the Agile methodology, including lower-level analysis of different stages of the process, benefits and purposes of each stage, and various best practices for different stages. I chose this post because it correctly emphasizes the importance the Agile methodology places on continuous delivery, which is something that has been a cornerstone for me in various projects.

A project that comes to mind is actually the same project I discussed in this week’s post for CS-343. A friend came to me and asked for something way above my skill level, and it was daunting to imagine planning out the whole project and implementing/deploying some large framework in any reasonable amount of time. If I hadn’t remembered something an old professional connection had said to me years prior, I don’t think I ever could have known where to start: “your code has to exist before it can be made better.” I think that is what the heart of these continuous delivery methodologies is really about, and it really is a true statement for many reasons. The first, which this blog touches on and which we have discussed briefly in class, is that your perspective will always be better or wider after the work is started. Another reason that statement holds true, and perhaps the most practical reason (at least in my case), is that half the time, I don’t even know what I am doing when I start. It would be impossible for me to design anything, because I don’t know anything. For me, learning my way through a project is almost all the fun, and that is not really an option without methodologies like Scrum and Agile, even if I don’t know I’m using them. This blog post discusses release management a lot, which is not so applicable to personal projects, but I think it connects nicely if you compare a release to a checkpoint or successful implementation of a new feature. In my project, as I built it, I started with: what. Then, I said, I guess I could try that. Then, I implemented a single shoddy feature. I saw my feature and saw a way to make it better. Compound that a hundred times, and I had a full framework that I had approached incrementally, following Agile principles and release management without even knowing it. I think that is a testament to the elegance of these continuous delivery oriented methodologies, and I will more consciously follow these principles moving forward.

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

High Quality Software Development

Podcast URL: https://www.youtube.com/watch?v=alUfh7Nk4eE

The podcast I chose is presented by Patrick Akil, and this specific episode features Eugene Fidelin. Eugene, as described on his LinkedIn profile, is an Engineering Manager and Frontend SME at eBay Advertising. The two participants discuss many subjects related to high-quality software development, including topics like bug prevention, testing, the balance between speed and quality, team performance, and many other subjects. One piece of advice, in case you would like to listen to the podcast, is that its timeline on YouTube is broken down into various topics, making it easy to find a specific subject

Many times, I start reading an article or listening to a podcast, and it does not hold my attention. However, this podcast kept my attention throughout its entire length for two reasons: the way it is produced and the way the topics transition from one to another. It is not very technical, which makes it easy to understand, and it dispenses the need for visual aspects deliver all the information. It feels very much like a conversation between two people who enjoy what they do.

While listening to the podcast, I took notes on a couple of topics and phrases that caught my attention. Right in the first few minutes of the podcast, Patrick and Eugene discuss resilience and predictability. They make a great point, stating that every program’s goal should be to be both resilient and predictable. However, creating software that is completely resilient can make it difficult to modify, meaning that adding or changing something could break a certain part of it.

The last three topics that caught my attention are all about testing. I believe they interested me most because I have not delved deeply into any kind of testing. The first topic is about good practices for testing programs, which includes testing the frontend and the API separately, and then running tests on both together. Another interesting topic related to testing is observability over prevention in edge case tests, meaning that sometimes observing behavior over time might be more beneficial than running tests on edge cases, especially since continuous testing of such cases may slow down the testing process. Another great comment was about which type of test to use for either frontend or backend; not every type of test will fit every backend, and not every type of test will fit your frontend design.

I plan to use this advice and these practices in my career to achieve better results. I would also like to highlight another topic mentioned at the end of the podcast: not every person fits every team. It takes more than just a resume to determine if someone fits the team’s style.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

What is Technical Debt

The Future you Problem

Photo by cottonbro studio on Pexels.com

Hello and welcome to a new week on this beautiful blog of mine. Today is a topic that is of interest to me and possibly everyone reading this. It could also be something you ran into during a coding project. It is called Technical debt, which is the concept of delaying or omitting work to complete a project but cause more work to do in the end. 

Let me give you an example that I have dealt with, and that you may have also dealt with. So you got a coding assignment to do right and that deadline is coming fast. So you set out to do it in the quickest and easiest way possible without a care for code layout or etiquette, it is just you working on it after all. The next day, you think to yourself that you may need to rework some facets of the code to make it run better or make it look neater. You then open up the project and look in horror at the mess you made and realize that it would take more time and effort to make it neater or run better than it would be to just continue on and get the project done. That is technical debt and yes it accrues interest.

The example was more personal and not that bad when you realize that the only price you paid is something you can’t stand to look at and also something that will take a long amount of time to fix. Like I said before it is just you working on it and as long as it works it’s fine…but what if you weren’t alone, say what if you were working in a team of 2 or 4 or perhaps a whole company amount. Then we have problems. Cause not only the debt is put upon others, but even money can be a problem if it is a company involved. 

There is also types of technical debt. Planned Technical Debt is meant to establish one presence in the market or gather feedback from customers, kinda like prototyping from my understanding. There is also Inadvertent Technical Debt when the developer is unsure of market requirements or aware of the architecture. 

Many things can cause technical debt to happen, such as poor management or the code not being reviewed well enough.  So to avoid such things it’s a good idea to 

  • Understand the Requirements
  • Understanding Decision Consequences
  • Supervising the Process

So be careful when coding a project as it may come to bite you in the future, so take into consideration the future you and help you out.

Be a Better Dev. (2020a, October 5). What is Technical Debt? (as a software developer). YouTube. https://youtu.be/2nDxKYIajoU?si=crpLGeoCewYZ_kEj

Eye on Tech. (2020b, October 7). What is Technical Debt and Why Does Tech Debt Matter?. YouTube. https://youtu.be/cdzUXv8SpjY?si=FHZ0Vl6ZVkhuSNeE

From the blog Debug Duck by debugducker and used with permission of the author. All other rights reserved by the author.

Psychology in Software Development

This week I discovered a blog that caught my attention. The blog discusses the incorporation of psychology into the process of software development. Spending extended periods seated, analyzing codes, searching for logical operations and function calls can exhaust our cognitive abilities. The fatigues could lead us to feel cloudy and have poor resolution. It goes deeper into the mind of a software developer mind on how one’s retain information, problem-solving approach, perceive the behavior and structure of what they’re building. It introduces study concept such as spaced repetition and interleaved practice that have been proven to enhance a person to learn new programming languages or frameworks. I believe that integrating psychological insights into software development can help enhance both individual mental well-being and professional skills.

The blog has eight topics, one of the first paragraph of the first one said,

“The project’s outcome hinged not on the technical challenges but on the interplay of personalities, communication styles, and the leadership structure within the team”.

“A team that communicates openly and respects each member’s input is more likely to solve problems effectively and innovate. On the other hand, a team mired in unresolved conflicts and poor communication can derail even the most promising projects.”

“A team that communicates openly and respects each member’s input is more likely to solve problems effectively and innovate. On the other hand, a team mired in unresolved conflicts and poor communication can derail even the most promising projects.”

“Linking these psychological insights to Agile practices offers a fascinating avenue for enhancing team-based methodologies. Agile’s iterative approach and emphasis on collaboration are well-suited to leverage the strengths of a psychologically savvy team.”

While managing my team during group activities on Methodology, I believe it is more beneficial for everyone to feel comfortable being their authentic selves rather than feeling anxious and reserved. I think the idea of Agile practices can assists them in expressing their ideas and feeling at ease within the group. Continuing to utilize Agile methods can result in increased efficiency and effective communication within a team to meet project deadlines.

“I recall an instance where a single line of feedback transformed a junior developer’s approach to coding. It wasn’t my code review that pointed out the errors; it was my remark about his unique problem-solving skills that made his eyes light up.” I concur that helping one another to solve a problem or code in an easier way because everyone have different background with coding. Therefore, feedback and mentoring is crucial when it comes to coding. One person code could load faster and less complicated than another. Positive reinforcement can amplify a person’s strengths.

Reading this blog helps me understand how psychology is integrated into software development. All of these aspects, such as team-work, leadership, problem-solving, cognitive biases, feedback, and coaching, can be advantageous when viewed through a psychological lens. It motivates us to improve ourselves and others by helping each other enhance our skills and cognitive abilities. Where we find inspiration daily.

Blog URL: https://betterprogramming.pub/integrating-psychology-into-software-development-c5f79fc8019e

From the blog CS@Worcester – Matchaman10 by tam nguyen and used with permission of the author. All other rights reserved by the author.

(Week-1) Agile and Software Development

Agile is a set of values and principles that software developers and/or managers use to encourage a positive work environment that is efficient, and promotes a successful workflow.  Agile is becoming the gold standard for software development and programming, because it is inherently based on collaboration.  Not only does it encourage intense collaboration with members of the development team, but also the customers they are making the product for.  A core tenant of Agile is to not only keep the team on the same page, but also stay transparent with the customer and accommodate their every need with the product.  Here are some important values and principles Agile is based on: “Working software over comprehensive documentation”, “Simplicity”, “Responding to change”, “Customer collaboration”, “Human communication”, and last but not least: “Continuous attention to technical excellence”.  These aren’t the only values, but they are some of the most important ones. 

“An Ultimate Guide to Agile Software Development” is an informative video about Agile Software Development, by the YouTube channel Invensis Learning.  In the video, the narrator discusses how Agile is beneficial for teams specifically in the Software Development field.  They describe Agile Software Development as a “set of iterative software development methodologies in which requirements and solutions arise from collaboration among self-organizing cross-functional teams”.  This is very important to understanding Agile, and its uses in the workplace.  Agile allows for teams working on different parts of a project to stay on the same page, and not get ahead of their peers, while still having room for improvement and disagreement.  They also go on to explain how a company following Agile doesn’t necessarily mean there isn’t a manager coordinating these things, but it suggests that each sub-group should be able to handle their problems on their own.  The video also discusses the “Agile Software Development Life Cycle”, which touches on how Software Development teams should roughly plan out their work for a product.  The cycles can differ from company to company based on the amount of employees, type of work, customer expectations, etc.  But, the values and principles should stay the same to maximize Agile efficiency.  The Agile Life Cycle follows six important steps, Concept, Inception, Iteration, Release, Maintenance, and Retirement.

To sum up today’s topic, Agile is a set of values and principles primarily used by software developers to make the workplace much more efficient and stress-free.  Agile promotes customer collaboration, and in-house collaboration with peers to ensure the product is as perfect as possible.  Over time, most software development companies will come to develop these principles, as they have been proven to be one of the best work strategies.

LINK TO VIDEO: https://www.youtube.com/watch?v=Evl5f2CnR08

  • Elliot Benoit

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

The New Methodology – Week 1

This blogpost by Martin Fowler was very interesting! It gave a very thorough and comprehensive look into what makes the agile methodology so different from older methodologies, which were very bureaucratic and abrasive when it came to change. It also showed why the principles of the more flexible, adaptive agile methodology helped to give more freedom to the developers and helped to create a better product for the developer’s clients. Reading all this put it into perspective for me how I will most likely be using this methodology in the future when I eventually go out to begin working and how this would really help to tighten up a team’s workflow and give them a better ability to put out a quality product. I really liked how as the post progressed there was a sort of small history about agile and how this blogpost was originally actually a means of pulling together most of the original ideas for the agile methodology in the past. I also understand now that agile really is just a perspective you need to have while working with a team and for a client that will help you to maintain a positive relationship with customers and maintain an efficient team. In the future I can assuredly see myself being apart of or using this methodology to develop software as it seems to be much more effective than older methods. The only thing I need to really look forward to is actually attempting to use the methodology as I don’t really have an understanding for how it would actually work or flow in practice. In essence, I think I picked this most of all because I still had questions about agile that have thoroughly been answered now, but I overall I hope for a chance to give it a try eventually in the future.

Summary: An in-depth discussion examining the difference in principles between the different methodologies of software process and an essentially original look at how agile developed and its methods, while also giving a sort-of mini history about agile and what it meant and means to developers.

Reason: I wanted a better more all-encompassing understanding of agile as I feel like I had heard this term outside of the course before, so I investigated it and came across this blog-post that seemed like it had a very detailed examination of it.

Blog Link: The New Methodology (martinfowler.com)

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

Exploring Software Development Methodologies: A Review

Blog Title: Exploring Software Development Methodologies: A Review

This week while searching for a blog I came across Kacper Rafalski’s blog post titled Software Development Methodologies: A Comprehensive Guide, which dives into the wide range of methodologies used in software development. From a few google searches I learned that Rafalski is a well established figure in the tech industry, known for his skills and knowledge in structured development processes, and his work provides insights on how various methodologies, such as Agile, Waterfall, and Lean, shape the success of software projects. In this post, Rafalski emphasizes the importance of choosing the right methodology based on project goals, team dynamics, and what a client needs. 

To start, Rafalski begins by explaining traditional methodologies like Waterfall, which follows a straight line in a downward sequential structure; this method is ideal for projects with clear, unchanging requirements. He contrasts this approach with the agile methodology, known for its repetitive and flexible approach, which accommodates changing client needs and fosters collaboration. Agile, according to Rafalski, prioritizes working software and client feedback over long and boring documentation, this makes it really useful in a fast paced working environment. He also highlights Lean one we have not covered yet in class hopefully soon. Lean is designed to  eliminate waste and maximize efficiency by focusing only on value-adding processes. He lastly mentions the newer methodologies, including Rapid Application Development-RAD and the Spiral model; each of them presented unique solutions for some particular project obstacles such as rapid prototyping and risk management.

I chose this blog posting for the following reasons: firstly, because it broadly and in great detail covers methodologies, highly relevant, therefore, to our course material. The tone of Rafalski is approachable and informative; he shows throughout by explaining complex subjects without getting too complicated on the reader.  I also liked his balanced discussion of the methodologies, which gave me the chance to think on how these approaches may apply to different software programming projects that I may encounter in my future. Also, the organization of the post makes it clear to follow and understand each methodology clearly. 

Reading this post clarified how to choose the appropriate methodology for a project. I really came to appreciate Agile’s iterative process and how in such an approach, adaptation to circumstances and collaboration is greatly enhanced, something that I hope to apply in future team projects. Generally speaking, I really recommend this post by Rafalski to anyone who wants to get a clear understanding of the diverse landscape of software development methodologies. This is not only an informative guide but also highly practical in field practice for software development.
Link to the post: Software Development Methodologies: A Comprehensive Guide

From the blog CS@Worcester – Harley Philippe's Tech Journal by Harley Philippe and used with permission of the author. All other rights reserved by the author.

Navigating the Upgrade of Outdated Codebases: Insights from Increment

In the world of software development, maintaining and upgrading outdated codebases is a challenge. That’s the reason why I chose this blog post titled “Ask an Expert: Upgrade Outdated Codebase” by the Increment team. Given that this topic directly relates to when class CS348 did an gitpod assignment on software maintenance. I’ve seen many other peers recommend this article as it offers expert advice on how to approach and successfully execute upgrades to aging codebases, ensuring they remain functional and relevant. When you’re faced with these questions, should you make the change, when should you make the change, finally how should you make the change. 

The Increment blog post provides 3 optional & practical strategies for modernizing outdated codebases. 1. A Big Bang Rewrite (changing the codebase from scratch and cutting over all users in a single conversion). But of course, this has its cons, such as being time-consuming and not seeing the process unless it’s all finished. 2. Tack the New onto the Old. The second option is to add new features built with new technology to the existing codebase. However, it’s not like you can just add in a new feature with the old and not touch up the old feature at all.  Outdated features are outdated for a reason, there has to be a balance. 3. A Hybrid Approach. Why choose one, when you can do both? Rewriting your entire codebase is a drastic and often un-recommended move. Adding new features to an old codebase is usually more manageable but can lead to serious issues. Therefore, finding the in-between. This option requires changing out the whole of your old code. But unlike the first option, the rewrite should be spread out over a period of time to minimize technical debt and financial cost. However, all these solutions have side effects, including this one. While you are updating, the technology could continue to advance and you’re left trying to catch up all over again or the specifics/goal changing as you are.

I really appreciate how the creator goes about explain their reasoning. I personally follow the motto: if it isn’t broken, don’t change it. But the way the blog presents actionable advice from industry experts, which is crucial for understanding the best practices in managing and modernizing legacy systems. Made me shift my thoughts a little. Change it before it becomes broken. As quoted from the blog, “it’s probably your last chance to fix the technology before it becomes irreparably broken.” 

Given that this topic directly relates to our course material on software maintenance and evolution, the insights provided are both relevant and timely. One key takeaway from the article is the importance of documenting the existing codebase before initiating any upgrades. Maybe even make another copy, it would be terrible to find out your “updates” ended up making things worse than before you decided to change it. This is definitely something I can expect to apply to future practices. 

I have learned a lot from this blog and for further reading, you can access the original blog post here.

From the blog SoftwareDiary by Oanh Nguyen and used with permission of the author. All other rights reserved by the author.

Modern Software Management: Key Principles and Personal Insights

In today’s digital world, good software management is critical for delivering high-quality products that meet user expectations and business goals. Modern software management refers to practices that help the software development processes. I decided on a source that highlights the key principles of modern software management, offering keen insights into how these practices enhance software delivery. While also having good project outcomes. This blog post summarizes these principles, explains their importance, and all while I’ll be providing personal reflections on how they align with my learning in my current course

The resource I selected talks about various aspects of software management, focusing on principles like Agile methodologies, Continuous Integration and Delivery (CI/CD), DevOps collaboration, user-centric design, lean software development, quality assurance, and data-driven decision-making. 

  • Agile Methodologies: Emphasize flexibility and collaboration, allowing teams to respond to changing project requirements efficiently. Not A tool, Not A method, 
  • CI/CD: Streamlines software delivery through automated testing and integration, improving the reliability and speed of releases.
  • DevOps: Promotes collaboration between development and operations teams, reducing silos and enhancing overall efficiency.
  • User-Centric Design: Prioritizes customer/user needs by using feedback and ensuring the software meets real-world requirements.
  • Lean Software Development: The main goal is to eliminate waste, continuous improvement, and maximize value throughout the development process.
  • Quality Assurance: Ensures the delivery of high-quality software through complicated testing and monitoring.
  • Scalability and Flexibility: Encourages designing systems that can scale and adapt to changing needs, ensuring long-term viability.
  • Data-Driven Decision Making: Uses metrics and insights to make informed decisions and drive continuous improvement.

I chose this resource because it provides a comprehensive overview of the key principles of modern software management, which happens to be the whole point of my class. These principles are directly applicable to the course material, which focuses on effective project management strategies and best practices for software development. Understanding these principles and getting an early understanding will help me in 0the future of this course. 

Personal Reflection and Application

Reading this resource helped me learn several key concepts from my coursework, particularly the importance of Agile methodologies and CI/CD in promoting flexibility and efficiency considering we had worked on it today. For instance, I learned how Agile’s iterative approach allows teams to remain adaptable, responding to feedback and shifting priorities without losing momentum. This makes sense to my personal experiences in group projects, where collaboration and frequent feedback were crucial for successful outcomes.

The resource also highlighted the value of user-centric design. A concept I deeply appreciate. As a programmer so far I feel, it’s easy to focus on technical requirements and overlook user experience. I realized all the projects I have worked on so far have been not user-friendly and you would have to know some competence in code to run them. 

Conclusion

The principles discussed in the resource have given me good exposure to help my understanding of modern software management. By getting the gist of  Agile methodologies, CI/CD, DevOps, and user-centric design in future classes, when we start talking about them, I will already be able to follow along and have a little foundation. 

Sources:

https://www.hakunamatatatech.com/our-resources/blog/principles-of-modern-software-management/

From the blog CS@Worcester – Zacharys Computer Science Blog by Zachary Kimball and used with permission of the author. All other rights reserved by the author.

Welcome to my blog!

My name is Luis Ruiz, this blog will be related to my CS-348 material!

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