With software development, working in teams is typically normal. Being able to work in a team is important. But what is also equally important is interacting with stakeholders. A team does not make a project just because, typically someone comes up to the team and gives an idea and the team gets to work. That is an extremely watered down version of how it happens, but that is how it works. This can be somewhat confusing so let’s break it down. 

In this blog post, they talk about what a stakeholder is, why they are important and then some examples of a stakeholder. The post defines a stakeholder as a group of people or groups affected by a software development project. They are in the best position to offer specific input on needs at their level. Essentially, they are people who know what they want for this project and those whose interests are important for the project. It is important to get their input on the project because they guide the project in a way. They are able to create a list of things that are needed for the project and a way for the developers to figure out what they are working on exactly. You do not want to ignore the advice of stakeholders and neglect them, as that means the developers are just making the wrong thing. But who is considered a stakeholder? End-users are good to consider, as they are the ones to be using it once it is complete. Knowing their input and how it affects them is important. People like managers, project managers, developers, and partners are all important, as they ensure that certain aspects of the project are doable. Certain authorities are also important to consider, such as shareholders or company owners. It is hard to get everyone in for a meeting on the project all at once, so getting representatives is a better alternative. Determining whether or not their input is needed is also important, as to not waste someone’s time. But again, how do you determine that? There are some questions you can ask, such as “who will be affected by this product,” “how will workflows change,” and “are there any people whose support is vital to the project.” 

Understanding who has valuable input and is able to shape the project will be key to you as a developer, as it lays the foundation and blueprint for what you and your team will be doing. It may be difficult to get everything everyone wants, and you may have to cut some things. But knowing when to do so is up to you and the team.

From the blog CS@Worcester – Cao's Thoughts by antcao and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I have found an article about encapsulation. Encapsulation is more than defining accessor and mutator methods. It also follows two main objectives hiding complexity and hiding the sources of change. To understand more about encapsulation, we will first need to understand the two concepts of modularity and abstraction. In the article, Edwin Dalorzo, the author of the article, uses the example of a car to understand abstraction. He says on this, “A car is complex in its internal working. They have several subsystems, like the transmission system, the break system, the fuel system, etc. However, we have simplified its abstraction, … we know that all cars have a steering wheel through which we control direction, they have a pedal that when we press it we accelerate the car and control speed, … These features constitute the public interface of the car abstraction” (Edwin Dalorzo). This is a great example because we can use abstraction to simplify unnecessary parts that the users would not need to understand. This concept is similar to modularity. In his book Code Complete, Steve McConnell said on complexity “ the interface should reveal as little possible about its inner workings”. So now that we understand the two concepts, the idea of encapsulation starts to unravel.

One of the things that we want to always encapsulate in Java is the state of a class. This should only be accessed through its public interface. Edwin says on encapsulation in Java, “In a object-oriented programming language like Java, we achieve encapsulation by hiding details using the accessibility modifiers … With these levels of accessibility we control the level of encapsulation, the less restrictive the level, the more expensive change is when it happens and the more coupled the class is with other dependent classes (i.e. user classes, subclasses, etc.).” (Edwin Dalorzo).  It is crucial that we keep this idea in mind while we design encapsulation for these public interfaces so that we can foster evolution of our APIs.

As talked about in the article, it is often wondered why we need to use accessor and mutator methods in Java, aka getters and setters. With encapsulation in mind, it is not there to hide the data itself but the implementation details on how the data is being manipulated. So once again we would need a public interface to gain access to this data. However, by exposing this data we risk losing encapsulation. So this is why we would need to encapsulate this information.

https://dzone.com/articles/why-encapsulation-matters

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

Until I can obtain a job, I will be working by myself most the time. This will inevitably impact my learning because working with others allows shared knowledge and experience for the parties to teach each other. The “Rubbing Elbows” pattern from Dave Hoover’s and Adewale Oshineye’s Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman discusses the benefits of collaborating with others.

The pattern mentions “Pair Programming,” a technique where developers code side-by-side. I have not coded in this manner in a long time. When I took my first computer programming class my best friend and college roommate was also taking that class. Given the circumstances, we often collaborated on assignments. While we did collaborate, we often coded the assignments solo and discussed our methods and problems. I cannot count the times that one of us would get stuck with an issue that the other had no problem with. I learned then that different programmers will find multiple solutions and methods while developing. These diverse techniques are worth examining and potentially adopting.

“Pair Programming” is not the only way to practice “Rubbing Elbows.”

“The goal is to find ways to expose yourself to the daily working habits of other skilled people, and observe the ways in which they gradually refine those habits into even greater skill. These habits extend beyond coding and into all aspects of software development.”

This statement from the pattern shows the type of knowledge the pattern will provide. “Rubbing Elbows” is not necessarily about learning new coding methods but about observing the small, often unmentioned details of a developer’s work habits. Because of this, developers can rub elbows by working on any part of the development process, including presentations or papers.

Working in LFP’s update module team provided plenty of learning opportunities for me. Some opportunities were coding related, while others were about project management.

I have a couple ways planned for practicing this pattern. Now that I am graduating, I think this would be a great time to collaborate on a project with my friend again. We have not worked together in years and this seems like an opportune time. He has been working in development for awhile and I am sure he has a lot for me to learn. I also plan on participating in the LFP spike-a-thon this summer. This will let me work on something familiar while presenting opportunities to work with other developers.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

I will hopefully be starting my software development career soon, and with that I will be joining a new team. Dave Hoover’s and Adewale Oshineye’s Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman’s pattern “Sweep the Floor” suggests “volunteer[ing] for simple, unglamorous, yet necessary, tasks” to contribute to the team. I will be one of the least experienced members in the team, so I’ll need to be proactive working on the more tedious work. Doing these tasks is more than just gaining trust from the team but also showing respect for the more experienced members. The experienced members should be focused on the work that requires their experience and not bogged down by simple chores.

“Examples of these tasks include maintaining the build system, production support, responding to maintenance requests, bug fixing, code review, eliminating technical debt, setting up the project wiki, updating documentation, acting as a sounding board for other people’s ideas, and so on.”

While it may not be fun work, these tasks are still important, and the team will be grateful for the effort. To practice this pattern, “Sweep the Floor” suggests finding the tasks that the team has been putting off and do them. The pattern however warns of the potentiality of being perceived as incapable of more vital work. This can be averted by working on more complicated issues or personal projects alongside the simple chores.

When reading through the list of example tasks, I could see the tasks that often held up work during our LFP sprints with code review being the biggest culprit. I can see how completing these tasks would be good to focus on when joining a new team. Not only will the team benefit from these tasks being done but completing these tasks will also give valuable insight into the project. With code reviewing, the opportunity to study the unfamiliar parts of a project is presented. Work on the documentation was also often put off or forgotten.

I think this pattern makes sense having the inexperienced members handling the simpler tasks. These tasks are chores to the experienced members of the team but are learning experiences for the inexperienced.

The pattern includes an experience of a developer working in a formal software apprenticeship. The important part of the story is when the apprentice watches Uncle Bob Martin, a master craftsman, take out the trash. The apprentice’s mentor then scolds the apprentice for allowing the job to go undone and having a master craftsman take care of it.

“It is not the job of the master craftsman to take out the garbage.”

This pattern has made clear what I will need to focus on when entering a new team as an inexperienced developer. I will need to find the simple, more tedious jobs and work on them while furthering my learning. “Sweep[ing] the Floor” will help with my integration into a team by familiarizing myself with the code base and team practices. I will also build trust with the other members of the team. Once I gain enough experience and trust, I can then start to work with more complex, interesting work.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

This pattern discusses the need to have good, quality feedback to allow for personal growth. Often times, the only form of feedback is coming from ourselves and what we have done. As discussed in the article, this can often cause our reflection and feedback to be skewed and biased. If you are on a very good team, it can cause you to either ride their coattails and feel more prepared than you are in reality or cause you to become overwhelmed and feel as if you know nothing. On the other side of the spectrum if you are on a bad team, it can cause you to become complacent because you are able to succeed easily on this team.

The way that this pattern offers a solution to this common problem is to be able to develop a test of actual tangible data that will allow for an honest form of feedback. For example, if you are in team but writing your own portion of code, have another teammate peer review your code. By having another pair of eyes on your own code, they will be able to pick up and point out portions of code that are bad, messy etc. that you would usually gloss over because it was how you had always done it. In a similar manner, if you have any supervisors or managers above you it is always a good idea to be asking for feedback from them. This will not only help you improve your abilities but will also show them that you have initiative to improve yourself.

I believe that this type of feedback is very important to get. Many times, people can become too complacent with their own skills and not try to improve or gain more knowledge. This has happened to me and the main reason I was able to realize my complacency was by working in a group project. By constantly collaborating with them it was easy to see my strengths and weakness and what needed to be worked on. By having the group give feed back and documenting the project as you go, allowed for you to see your progress in a tangible sense.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

This pattern begins by discussing the desire to get into the software development field with the drawback that often times managers or HR won’t hire without experience. To be able to show that you can become an effective member of the team, you need to be able to translate all of the knowledge gained previously into concrete skills. A good way to show these concrete skills is the capability to demonstrate that you would be able to make an immediate positive impact to the team, even if that impact is something very basic. By showing these concrete skills, it will give you a leg up on the competition when hiring.  HR is already taking a chance on you; it is best to show that it will not be for nothing and you are at least capable of something beneficial.

The way to go about this that the article discusses is by going through CVs or anything that shows the concrete skills that well-respected professionals list about them. Then find which one(s) of the skills are applicable to whatever team you are trying to join. From there, work on being able to demonstrate that skill as a concrete ability, whether it be by doing a pet project or simply practicing that over and over.

I believe that this pattern is something very important to learn. As someone who is just getting started into the software field, it can often be hard to even get a foot in the door for some companies. When you finally are able to get in the door, it is absolutely essential that you show that it was not a waste of time. The most successful interviews I have had was when I was put in front of a team leader who wanted me to demonstrate certain skills that would be able to help them immediately. Often times it is simple problems that are needed to be shown, but it is very important to show that you not only understand the problem but are able to apply the solution. A hiring manager is far more likely to “take a chance” on you if they think you’ll be able to immediately have useful, applicable skills for the team.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

https://www.softwaretestinghelp.com/early-testing/

This week I read the post from the site linked above. It talks about effective quality assurance strategy in the early stages of a project. Uncaught bugs or fundamental flaws in the foundations of the software life cycle can result in setbacks for the later stages. Ultimately, it is more efficient to test early and test often than to spend resources going back to fix an early issue. If this is the case, sometimes the best solution is to rewrite many built features of a software project just to change the foundation, which is the worst case scenario in a time crunch environment.

There is a balance to be achieved between spending enough time testing early as to not create fundamental mistakes, and spending too much time testing without devoting enough resources to producing a working prototype. Software projects are typically planned on a time based release quarterly, half-yearly, or yearly, depending on the size of the project and the goals in mind. Because time is of the essence, defects need to be organized based on severity, time allocation, and expected collateral impact for the rest of the code.

This cycle can be broken down into steps; the developer creates, the tester tests the creation and ranks severity, the developer responds by fixing the most important issues, and the tester evaluates the fixes. Ultimately, this cycle never ends as long as they are employed. Constantly, there are new features and new bugs, and it is impossible to discover every bug from every new feature, the product is never defect free. In this way, testing is especially important in the early stages of development since it plays better into the long term which we expect to never end.

Now that I’ve summarized why and how early testing occurs, the final segment of the site reviews the primary targets for early testing. To begin, stakeholders determine which features will be the most effective by generating the most revenue, complying with standards, catching up to a competitor, or succeeding a competitor. These selected new features are the focus of early testing since they usually involve many lines of code with a high possibility of intersection. QA and development leaders both need to work together when working on these high priority features in the early stages of development. This collaboration must be stressed as especially important to the work efficiency of the entire project.

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