Guide to Successful Software Development Team Management by Aimprosoft

For this blog, I chose to write about Team Management since its been a huge focus in both my CS-343 and CS-348 classes this semester. Since the beginning, we’ve been working in groups on in class activities so reading about this topic was something I could relate to.

The blog is an interesting and helpful guide on how to lead software teams effectively. It begins by explaining the importance of having good management, it helps complete projects on time, keeps project within budget, and overall makes the team more productive and happier. Overall, what stood out to me was the idea that having successful team management is not about one person controlling everything. Instead, it involves everyone, planning, and tools rather than just having technical skills.

Many things that I learned from this blog connected to stuff we’ve discussed in class such as Agile, Scrum, and Kanban. Seeing these methodologies being explained in a real world guide made it a lot easier to compare the differences. It explains that Kanban doesn’t use time boxes like sprint cycles that Scrum uses. Instead it focuses on visualizing everything and limiting how the number of things that are in progress, and keeping work flowing steadily. It notes that Kanban is great for teams that get more incoming requests, whilie Scrum is better when you have clear goals and a stable team. I also learned that some teams even mix both approaches.

What I took from this blog was how important it is to have open and constant communication. I used to think that having a successful team would require expert coders to lead but that isn’t the case. In our class and from this blog it’s shown me that communication, strong organization, and planning is far more important. It motivated me to start improving on these skills myself as it’s just as important as being a great programmer for this career. In group projects, I plan to contribute more, making sure that everyone is on task, as well as everyone giving their opinions. Improving these skills right now will definitely help me advance through my career.

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

Code Refactoring and why should refactor your code by Lazar Nikolov

For this blog post, I chose to write about Code Refactoring. Nikolov starts off by expressing the idea that software does not expire, but it rots over time. The program continues to work, but as we add quick fixes, messy code, and shortcuts, it begins to become harder to work with. What is refactoring? In simple terms, refactoring is the process of cleaning and improving code without changing what the program actually does. To do this we must find code smells and technical debt and then begin removing them.

Code smells are not bugs that causes problems to your program. Instead they are warning signs that something is wrong with the design even though the code runs. Some examples of this can be having very large functions that try to do more than it should, confusing names, and complex logic that is hard to follow. Code written this way is often closely tied together. This could cause changing one small thing to break another part.

Technical debt is what happens when we choose the fast and easier solution like a shortcut to fixing a problem. This happens when we’re rushing to meet a deadline or don’t have coding standards. As a result we pay the price later with extra work since the code is hard to fix and improve on.

When should you refactor your code? Some signs are repeated code, having many bugs, or you are unable to add a new feature since the existing code is hard to work with. This relates to a term we’ve learned in class known as DRY (Don’t Repeat Yourself) and AHA (Avoid Hasty Abstractions). DRY says we should not repeat the same logic many times in our code. AHA reminds us we shouldn’t create abstractions early on.

This blog made me realize how much I relate to this topic. As someone who can say they often procrastinate and usually does assignments at the last minute. I’ll write quick code that “just works” so I can finish my assignments. I rarely think about how I can improve or add to it later. But I now understand that these shortcuts will definitely turn into technical debt. Moving forward, I’m going to watch for code smells more often as I work on projects. My goal is to write more optimized, cleaner code that would be better in the long run.

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

For this quarters blog, I decided to write about Coding Standards and chose to read Why You Need Coding Standards by David Mytton. To start off, Mytton talks about what does “proper” code really mean. It is not just any code that works, but rather code that is easy to fix, add to, and update in the future. His blog mentions a common problems that we face today. Many developers start learning code with their own style which only they might understand. Once a project grows and other people join in, different styles will collide and make the code confusing. Mytton explains the frustration of working with messy code and how stressful it is to scroll through long, unclear code with confusing variable names, missing comments, and code without spacing.

There are two main examples that were used to show the difference that coding standards make. Both examples were written in PHP, the first example was messy. There wasn’t spacing, variable names were unclear, no braces around control structures, and long conditions missing parentheses. Although it technically worked, it was definitely hard to read at first. The second example showed the same logic. This time around there was clean formatting, clear variable names, proper indentation, and braces correctly placed. I’ve never used PHP but it was obvious that the second example was much easier to understand.

I selected this blog because recently in class we’ve been working on clean coding and realized how hard it can be to understand code written in different ways. I also wanted to further my understanding of how professionals handle this problem and how they keep projects organized. I think that this blog was able to explain that point in a simple and relatable way for me.

From this blog I learned that coding standards are beyond just “good habits.” It prevents confusion, reduces mistakes, and allows projects to run more smoothly. I also learned that a coding standard is not something that just one person creates and uses for themselves but rather by the whole team. I hope that I am able to fix my poor coding habits and write code that allows others to collaborate with my work. I think before this, I didn’t care much whether somebody would be able to read my code but rather if it was able to run then I was satisfied. My mindset has changed and I want to be more consistent with following coding standards.

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

For this quarters blog post, I wanted to write about SOLID design principles and chose SOLID design principles explained written by Phillip Johnson to better my understanding. During class activities we learned about design principles, specially object oriented programming which goes in hand with SOLID. Johnson’s blog explains these ideas in a clear and real-world way, using examples from different programming languages that we don’t use in class like Ruby and C#.

In Johnson’s post, he begins by sharing his personal experience when he first encountered SOLID through Sandi Metz’s book and how it helped him write better code across different languages. SOLID originates from an essay written by Robert Martin, also known as Uncle Bob in which he emphasizes that “successful applications will change and, without good design, can become rigid, fragile, immobile and viscous. These are some terms we learned in class. SOLID stands for five key ideas: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion.

Single Responsibility: we should avoid making multiple tasks in one class. Johnson’s example refactors database and file operations into separate classes. Open/Closed: extend behaviors without altering existing code, essentially if we wanted to add/change functions in an existing class then we should be able to do so by extending the class instead of modifying it. Johnson also uses the duck example that we worked on. Liskov Substitution: sub classes should work just like their parent classes. We shouldn’t be making overrides that change expected behaviors. Interface Segregation: Use small, specific interfaces instead of big ones. Johnson’s example uses ducks and fish, and how we should separate each behavior just like we did in our Design Patterns homework. Dependency Inversion: rely on abstractions and not specific details. Basically, High-level code shouldn’t depend on low-level details.

From Johnson’s blog, I was able to learn more in depth about what SOLID is, how each of the principles connect, and how to find code smells. I think his post helped me understand our previous Design Patterns homework even more than I did while completing it. What stood out to me most was that the blog didn’t just explain what SOLID is. It showed me why these principles matter in real code. I realized that creating good code isn’t just about make it work once, but rather about making it easy to maintain, refactor, and improve over time. Because of this, I want to prioritize using SOLID a lot more in my future coding projects so that my code remains clean, adaptable, and easy to extend.

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