In class, we had the in class activity about inclusive and insensitive writing. This assignment was able to open our eyes on vocabulary choices that we didn’t even notice as being potentially harmful to others that might be reading our work. This got me thinking about if anyone else has been using the Alex JS linter and if they have posted anything about their feedback and experience while using it. From my searching I found a blog post called, “Refactoring condescending language with alexjs” by Suzanne Aitchison. This blog focused on their experience with the Alex JS linting tool and what led them to start thinking about their use of words and tone when writing their work.

The blog started with what got them thinking about their use of tone and content when writing . They mentioned how they were told to focus on words such as “easy” and “simply” because to some people the task at hand might not be so simple or easy to them which can be very discouraging and have them lose motivation. The Alex JS linter focuses on, “gender favoring, polarizing, race related, religion inconsiderate, or other unequal phrasing in text” which covers most of the types of insensitive ways of writing. In the author’s experience when they used it on their own work they had 104 warning of insensitive writing that all fell into common groups. Which happened to be the use of “easily”, “simply” and “just” which we now know is insensitive to people who may not find certain tasks easy. In addition, they also ran into one of the negatives of the linter which is false positives. In this case, it was flagging words like “color” and “special” which fall under the list of insensitive language however in this context it was not. Their takeaway from working with Alex was that their default way of writing will need some work that can be taken as insensitive and Alex is a tool that helps them in making their work more inclusive.

After reading Suzanne Aitchison’s blog, I found the reading very helpful because it further pushed me in the right direction of working with more inclusive language as well as pointing out things that I did not catch when we were working on our exclusivity activity in class. I feel like as we progress as a society and we are working on becoming more inclusive tools like Alex JS will be very helpful. When we first started the in class activity I didn’t see a problem with some of the flagged words however after seeing why they were being flagged as well as reading the blog I am increasingly understanding how certain words can be taken from those that come from other backgrounds than I do. My main takeaway from this will be working on using more inclusive language and making sure that my work can be taken in a positive note from whoever reads it.

https://dev.to/s_aitchison/refactoring-condescending-language-with-alexjs-3ifp

From the blog CS@Worcester – Giovanni Casiano – Software Development by Giovanni Casiano and used with permission of the author. All other rights reserved by the author.

Clean code refers to computer code that is easy to read, comprehend, and maintain. This type of code is crafted to be straightforward, concise, and expressive, following specific conventions, standards, and practices that enhance readability and clarity. 

The importance of clean code cannot be overstated. When code is readable and comprehensible, it facilitates collaboration among developers and boosts productivity while minimizing errors. Additionally, easy maintainability is crucial for long term projects, ensuring that the codebase can be updated and enhanced over extended periods. The foundation of clean code lies in its readability and maintainability, as beautifully articulated in the blog “How to write clean code?” By FreeCodeCamp. In this article, we’ll dissect the principles and practices behind clean code, and give you a few tips on how to craft clean cod.

Assessing Code Cleanliness

Determining whether code meets the standards of cleanliness involves various aspects. Good documentation, consistent formatting, and a well-organized codebase serve as benchmarks for clean code. Additionally, code reviews and thorough testing contribute to identifying potential issues and ensuring adherence to best practices.

By incorporating tools, practices, and conventions, developers can create a codebase that is efficient.

Tips for writing clean code:

1. Effectiveness, Efficiency, and Simplicity
   • Prioritize effectiveness to ensure the code solves the intended problem.
   • Strive for efficiency by optimizing resource usage.
   • Embrace simplicity for code clarity and easy comprehension.
2. Format and Syntax
   • Enforce consistent indentation and spacing.
   • Maintain a uniform syntax throughout the codebase.
   • Adhere to consistent case conventions (camelCase, PascalCase, snake_case).
3. Naming
   • Choose clear and descriptive names for variables and functions.
   • Avoid vague or generic names that obscure the purpose of the entity.
4. Conciseness vs. Clarity
   • Strike a balance between concise and clear code.
   • Prioritize clarity to enhance readability, even if it means sacrificing conciseness.
5. Reusability
   • Design code with reusability in mind, promoting efficiency in development.
   • Embrace modular and scalable software architectures.
6. Clear Flow of Execution
   • Ensure a logical and clear flow of execution in the code.
   • Steer clear of spaghetti code through thoughtful organization and structure.
7. Single Responsibility Principle (SRP)
   • Assign a single responsibility to each class or module.
   • Enhance code readability and maintainability by adhering to SRP.
8. Single Source of Truth
   • Centralize data or configurations to avoid duplication and ensure consistency.
   • Simplify updates by having a single source for critical information.
9. Only Expose and Consume Needed Data
   • Minimize exposure or consumption of unnecessary information.
   • Utilize object destructuring for selective access to required data.
10. Modularization
    • Break down code into smaller, manageable modules for ease of understanding.
    • Foster reusability and maintainability through thoughtful modularization.
11. Folder Structures
    • Organize the project based on features rather than file types.
    • Cultivate a clear and logical folder structure for seamless navigation.
12. Documentation
    • Employ comments to provide context and explain the functionality of the code.

Reference: https://www.freecodecamp.org/news/how-to-write-clean-code/

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.

Fundamentally Agile is a very flexible and effective methodology that allows teams to continuously provide a working model of their respective project. When compared to the Waterfall methodology, Agile may seem like a flawless approach to team development and management, however this comparison to Waterfall fails to capture Agile’s flaws. Ideally, by understanding Agile’s feats and flaws, teams can make the most of the methodology.

Agile works best when all members deliver their respective parts of the project on time. This creates pressure on the developers to reach that time quota, as a result they may be more inclined to ‘cut corners’ so to speak while developing their part. Creating faulty code (or a general product) may lead to future issues, which would likely lead to sprint backlog bloat, so the development methodology must balance the value of the work being created and the time being spent to create the aforementioned work.

On the topic of time management, Agile does not offer much flexibility while creating sprints. Sprint length is determined towards the beginning of development, this itself is an issue as developers lack the foresight to allocate enough time in a sprint to take on larger-scale projects. Sprints encourage segments of digestible work for the developer, as Bryar and Carr mention in the article Have We Taken Agile Too Far?, “rather than take the time and uncertainty to develop a new capability, they go with the skills they currently have” (Bryar & Carr). Due to time constraints, developers settle with what they’re most comfortable with, as opposed to seeking potentially more effective solutions. This damages the final product as it heavily depends on the developers’ current experience and does not promote research.

One solution to this issue would be shifting to the Epic-model. Here developers won’t face an imminent time constraint that sprints impose, rather they will take a task (a story) and aim to complete it before the team moves on to the next step (the epic). This type of work structuring does not intrinsically have a set time limit but can be integrated within the Agile methodology. The goal of combining these two types of work structuring is to create a process where developers can have assigned tasks that are components of a larger task, AND to have a flexible time limit before moving on to the ‘larger task’. Another solution would be to fundamentally change how Agile works within a team. Currently, there are very few exceptions to change the duration of a sprint period, so to shift to a variable duration of each sprint would change how Agile works. A downside of doing this would be removing the consistency between sprints, but the benefit of that is that developers may be able to take on more work or do more research into their respective tasks before delivering their first working model. As a development methodology Agile should benefit the developers, therefore shifting from a rigid (preset) working period may increase the quality of work.

-AG

Source:

https://hbr.org/2021/04/have-we-taken-agile-too-far

From the blog CS@Worcester – Computer Science Progression by ageorge4756 and used with permission of the author. All other rights reserved by the author.

While attending my previous university, Becker College, I was introduced to Scrum, Agile, and Kanban with very surface-level information. As we progressed through this current semester, my knowledge of both Scrum and Agile increased, with my knowledge of Kanban tailing behind. So I seek to answer the question of ‘What is Kanban’?

Kanban, similar to Scrum, is a type of work structuring that places importance on visual responsiveness and flexibility. Scrum and Agile run on the idea of sprints, which Kanban does not naturally have, but rather it opts to focus on a time cycle. Time cycles measure how long it will take a single task to move through all stages of development. A potential flaw here would be that if the team agrees upon many stages of development, such as adding multiple testing stages, then the average time cycle will take longer. By not imposing a static time limit, such as those provided by Sprint structuring, it encourages developers to put as much effort as possible into their respective task(s). The key to an efficient team would be to optimize these time cycles and get their average down to shorter periods while maintaining the quality of work.

Within the development process, each task is represented by a card and will move through the Kanban board as it advances in the development cycle. This board helps create the visual responsiveness that Scrum lacks. If a card is stuck in one phase of development, then fellow developers may take notice and help push it to the next stage. While visual responsiveness does help to grant a sense of worth seeing tasks being completed, it best serves as a collaborative tool between developers which further increases team efficiency.

Kanban would be my preferred choice of work structuring as I find that the Kanban board is an incredibly useful tool to both track and collaborate with your team. However, one glaring issue I do have with Kanban is the lack of a direct CD (continuous delivery). Scrum will have the Sprint Review and Retrospective which gives the development team a chance to show their current working model of the project and get suggestions for it. Kanban lacks this dedicated period to show the project and communicate with their partner. This runs the risk of high-effort work being rendered useless as it’s not what their business partner had in mind. Additionally, with the lack of a Retrospective, the team will not have a dedicated period to reflect on their progress and comment on places they may optimize their work. A solution here would be to create sprint-like periods where no work is due, but at the end of the period, developers will have both a review session with their business partner and a retrospective within the team. This increase in general communication will ensure the product will be created effectively and will meet all requested specifications.

-AG

Source:

https://www.atlassian.com/agile/kanban#:~:text=What%20is%20kanban%3F,of%20work%20at%20any%20time.

From the blog CS@Worcester – Computer Science Progression by ageorge4756 and used with permission of the author. All other rights reserved by the author.

As a beginner coder, I’m always learning new things about the software development world. This week, I read an article that made me think differently about “clean code,” something I thought was the ultimate goal for every developer.

The article, “Goodbye, Clean Code” by Dan Abramov, explained that while clean code is important, it’s not the only thing that matters. It’s like a tool we use to make code easy to understand, fix, and test. But sometimes, focusing too much on making code perfectly clean can actually slow us down.

I can totally relate to this! When I first started coding, I was obsessed with writing “perfect” code. I spent hours making sure every line was exactly right, even if it meant the code didn’t work as well. This approach didn’t really help me learn or be productive.

Instead of aiming for “cleanliness” all the time, Abramov suggests that we should focus on writing code that solves the problem we’re working on. This code should be clear, easy to understand, and easy to change if we need to. This way, we can learn more about coding and be more productive.

One of the things I really liked about the article was the idea of “incidental duplication.” This means that it’s okay for there to be some repeated code, especially when we’re first starting out. Of course, we don’t want to have a lot of repeated code, but a little bit is okay.

The article also talks about how important it is to work well with others when you’re coding. This is because we often share code with other people, and if we change someone else’s code without talking to them first, it can cause problems. This reminded me that coding is a team effort, and we need to communicate well and respect each other’s work.

Overall, “Goodbye, Clean Code” was a great read for me. It helped me understand that clean code is important, but it’s not the only thing that matters. It’s more important to write code that works and that we can understand and change easily. This is something I’ll keep in mind as I continue to learn and grow as a developer.

Link: Goodbye, Clean Code: https://overreacted.io/goodbye-clean-code/: https://overreacted.io/goodbye-clean-code/

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

During this last week of class, I have been learning about clean code and how to write it as well as edit my previously written code in order to follow these guidelines. Clean code is exactly what it sounds like. It is code that is easy to read and understand, and isn’t too complicated or formatted poorly. Learning how to write clean code is going to be vital in working in the computer science industry. Everyone in this industry works with another programmer at some point in time, so having clean code will make their life and your life easier. While researching more about how to write clean code, I found a website called freecodecamp that does a great job explaining attributes of clean code while also giving examples. On top of explaining how to do it, it also has a section explaining why you should care about writing clean code. Personally, this really helped me understand why clean code is needed and why it is very important to understand.

The three main aspects of clean code are effectiveness, efficiency, and simplicity. Effectiveness is pretty self-explanatory. It means that the program should be able to solve the problem that it was designed to solve, otherwise it isn’t helpful. Once the program is considered to be effective, we need to also make sure that it is efficient. If a program solves a simple addition problem, but takes 36 hours to run, the program isn’t efficient as there are much faster and more simple solutions. If your program is post effective and efficient, then you also need to make sure that it has simplicity. While most sites will have different qualifications for simplicity, I think freecodecamp has most of them. Freecodecamp wants everyone that is trying to write clean code to ask themselves these questions about the code:

1. “Can you easily understand what the program does at each line?
2. Do functions and variables have names that clearly represent their responsibilities?
3. Is the code indented correctly and spaced with the same format all along the codebase?
4. Is there any documentation available for the code? Are comments used to explain complex parts of the program?
5. How quick can you identify in which part of the codebase are certain features of the program? Can you delete/add new features without the need of modifying many other parts of the code?
6. Does the code follow a modular approach, with different features separated in components?
7. Is code reused when possible?
8. Are the same architecture, design, and implementation decisions followed equally all along the codebase?”

While there are a ton of other ways that you can improve your code, these are the 3 main factors. Without these 3 foundational factors, you wouldn’t be able to write clean code which would make life harder for you and for everyone that reads your code.

Synopsis: https://www.freecodecamp.org/news/how-to-write-clean-code/#what-does-it-mean-to-write-clean-code-and-why-should-i-care

From the blog CS@Worcester – One pixel at a time by gizmo10203 and used with permission of the author. All other rights reserved by the author.

Software Process Model

A software process model is an abstract framework that gives steps on ways to plan software development processes and how they can be organized and executed. There are different types of software process models but all include some form of:

• Specification – Defining what the system should do
• Design – Defining the structure of the system
• Implementation – Implementing the system
• Validation – Ensuring the system works as intended and that the system is what the customer wants
• Maintenance – Changing, modifying, updating to keep up with the customer needs/fixing bugs

Types of software process models

There are many different types of models that are available to be used by organizations. Some allow organizations to use the model directly while others are more flexible, allowing organizations to create custom steps that are more specific towards their needs.

Software processes are typically specified using Software Development Life Cycle (SDLC) models. These models specify the different steps of the software development process and the order they are executed. 

Waterfall Model

The waterfall model breaks down software process activities into sequential phases. Each phase depends on the outcomes of the phases before and cannot be started until all phases prior have been completed. Each phase corresponds to a software process. For example, the first phase would be specification/requirements analysis because developers cannot create a system without knowing its intended function. Once that step is completed, then the next phase can be started and so on.

V Model

The V model is similar to the waterfall model where steps are followed in a sequential order. Initially after each step, the model progresses downwards to move onto the next step. Once the the coding/developing stage is complete, the model then bends upwards to create a V shape. This model highlights the relationships between each phase of the development life cycle and its corresponding phase of testing. The downward process is called the Verification Phase, while the upward process of the model is called the Validation Phase which are completed by developers and testers, respectively.

Agile

Unlike the two previous models, Agile is not a model with specific steps to follow. Rather Agile is a broader term for a set of methods and practices that encompasses values from the Agile Manifesto. These values helps teams to react quickly to any unforeseen changes, while reducing risk. The software development approach to Agile is usually rapid and small cycles. Doing this results in more frequent releases with each building upon the previous releases. Agile can be implemented by using frameworks such as Scrum and Kanban.

Reflection

I chose this resource because before simply listing different types of models, it clearly defined what the software processes are. This ensures a foundation is established. Although only three of the models in the article are listed above, there are several more models which I found interesting as I was unfamiliar with some of them. Because organizations use different models, being aware of the more popular ones will be beneficial in the future.

Resources:

https://www.visual-paradigm.com/guide/software-development-process/what-is-a-software-process-model/

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.