Category Archives: business

Sprint Retrospective: Learning to love Group Projects

Hi Debug Ducker here, and I just recently finished my first sprint with a group project. I have to say it went well, better than I expected. This coming from someone who has had poor experiences with group work.

Let’s begin on what exactly was working on for these past months. You see I was assigned to work on a project based on my college campus’s food pantry. We were assigned to work on an Inventory culling system based on the expiration dates of the products on the shelves. To say that I had way more different expectations of what needed to be done would be an understatement but I am getting ahead of myself.

Back to the main project, I am in a group of five and we came up with several ways to approach this project. We decided that we should split the work, two would work on a scanner that would check the items’ barcodes for identifying product information and the other 3 would work on the backend for the function of culling the inventory.

I found that working on separate parts of the project worked well in the long run allowing people to focus on one of the many aspects of the projects. Especially with the amount that got done at the end. I would know as my part of the project was going well….sorta. 

There was some trouble, such as using an already established code as the base for the project. It made me realize something, I wasn’t sure how to approach the issues as the code base was made with and due to my lack of knowledge of JavaScript, it was going to be problematic. Fortunately, I had 2 other companions that could assist me and did a great job. From this, I seek to improve my overall knowledge of JavaScript and seek ways to utilize the code base better.

Recently I read a bit of a programmer mentoring book called Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. This experience reminds me of a pattern that I resonated with. Accurate Self-assessment, basically identifying what you know and what you don’t. A self-reflection of my skills and I found out that there is more that I can learn. I want to see this project succeed so I think I need to brush up on some skills that I am lacking so the project can come out great. That pattern is a good encouragement for me to study further.

Near the end of the project I was worried that it wasn’t going to be complete by our standards, fortunately, the other group got the scanner worker to find it, and we made some progress on the backend but I found that it didn’t reach our goal of what we wanted it to do. In the end, we were satisfied with our progress and hope to continue integrating the rest of the work.

Here is most of the work I have done it was mostly focused on trying to figure out testing our culling system and integration of product schema.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/guestinfobackend/-/tree/main/specification?ref_type=heads

Here is the backend for the rest of the work done in collaboration with the others

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/guestinfobackend/-/tree/main/src?ref_type=heads

Thank you for your time, Have a nice one.

From the blog CS@Worcester – Debug Duck by debugducker 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.

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.

Project Management

Source: https://monday.com/blog/project-management/guide-to-project-management/

The title of this blog is “What is Project Management? The Complete Guide [2024].” As seen from the title, this blog obviously describes the ins-and-outs of project management. The idea of project management is to manage projects by ensuring that they are delivered on time, within a set budget, and satisfy the needs of the stakeholders. Project management involves setting goals, scheduling, managing, monitoring, and collaboration. This is accomplished through various methodologies such as Agile, Kanban, or Scrum. This is an important field, and topic, because teams of individuals are the ones who provide the greatest projects and products to the market, and without effective leadership and problem solving, they would never come into fruition. Many different organizations employ project managers, ranging from small businesses to Fortune 500 companies. Project management is not exclusive to software engineering though, it can be seen in other sectors such as construction or marketing. “The Project Management Body of Knowledge (PMBOK Guide) defines ten key project management knowledge areas” them being: scope management, schedule management, procurement management, stakeholder management, risk management, communications management, resource management, quality management, cost management, and integration management. These are all self-explanatory from their names but are very important for being an efficient and effective project manager. There are many different tools used in this field, such as Gantt charts (used for scheduling and tracking tasks in a visual timeline), tasks lists, Kanban boards, calendars, budget trackers, mobile apps, and many others. One might ask if a project is completed and another one is about to be started, is everything created from scratch? The answer is no. Project managers use templates to fill in instructions from prior work to save time when initiating a new project. There are quite a few roles in project management, one being the project manager themself, the project sponsor, the team members, the stakeholders, the customer, the office, and the steering committee (who provides oversight). All of these individuals make the creation of projects operate smoothly.

I chose this particular post about project management because it appeared to be all-encompassing of the topic, and I was correct. After learning about Agile and Scrum methodologies in class, I was interested in learning about the importance of having a project manager in various sized companies. I can appreciate the fact that they have to communicate with stakeholders, engineers, and management in order to ensure smooth operation. Overall this material was very interesting to me because I’ve had an interest in this field for my future career. If I end up pursuing project management, this information would definitely be beneficial for performing my job appropriately. If I don’t, knowing the role of a project manager would be beneficial regardless because I’m bound to work with one regardless. Having an understanding of your coworkers’ roles at your company is important for collaboration. 

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.