Sprint Retrospective – Round Five

A reflection on what I learned from this week’s sprint is that establishing a working line of communication between multiple groups working on a singular product plays a large role on the work flow. The “Theas-Pantry” repository is currently utilized between two different sections of the same class. As each section is either in a separate time slot or day of the week, there is no physical communication between both groups.

In order to solve this communication problem, it is presented to us to use a communication program called Slack. Within this program, there is an established group that allows communication between the following groups: all class sections, professors, and owners of the food pantry. However, a second line of communication can also be established on the repository in the form of discussions found on independent issues posted within the repository.

The theorized result of the primary communication program, Slack, is that all related groups will be periodically or frequently communicate with each other. If this is the behavior that exhibits through the limited development time, which is the length of a single semester then there should be significant productivity between both groups.

However, this was not the behavior that was observed during the development time. The slack group made available to the students is under-utilized in two ways. This first way is surprising, which is between the members of the same group. I suspect that this is the result of being students and having other priorities where the project is second to completing course work for other classes. In the second way, which is not surprising, is communication across multiple groups.

The core lesson of communication comes from the in-existence of communication between multiple groups. One major example of an issues that arose from this lack of communication is within the process of establishing and managing the project within GitHub. There were task duplications, wrongful closure of tasks, mismanagement of branches and many more. It was only until the middle of April where a successful link of communication was established to rectify the situation. If both teams took the communication aspect of group work seriously, the problems found should have been minimal or solved relatively quickly.

Although many of the issues have been solved as of today, only one on-going mystery remains. There is a possibility that both groups do not have a clear idea of what the other group is doing. We hope to sort this out, as both groups seem to deem the other as the one at fault for any issues that arise. This is the not ideal work environment in any situation and is likely a product of poor communication.

During this sprint, I focused my efforts on solving the communications problem as described earlier in the blog. This includes updating descriptions of GitHub issues that lacked a meaningful description, removing duplicate or irrelevant issues created, or removing older Git branches. Other things that I worked on would be creation of newer tasks as indicated by our recent meeting with a representative from the University’s food pantry. Finally, the last significant thing I worked on would be finalizing the initial creation of the back-end, where it currently only serves a purpose at redirecting data from the intake form app to a server. I can only hope the last sprint finishes strong so that a working product can be presented.

Sprint Retrospective – Round Four

            A reflection on what I learned from this week’s sprint is that a poorly managed repository will create problems for your team and slow down the progress. After translating the work done in Java to Angular during our restart from last sprint. The initial IDE used was an online IDE called StackBlitz however this was abandoned for WebStorm a week later. This is because we weren’t able to successfully connect it to any repository so that other members could make changes. At this point, we downloaded a copy and started to transition into WebStorm.

            During this transition, we decided to get a working copy into the GitHub so that everyone from both groups can work on it.  However, we did not make note that a properly structured repository is important. In this iteration of the repository, the root folder did not include all the necessary files needed to function correctly. The necessary files were not exactly missing from the upload but rather located in the only other subfolder. This subfolder was generated since we downloaded a copy from StackBlitz. By placing this subfolder into the original root folder, we had plenty of workarounds to make the project work normally.

            At this point in time, instead of importing the root folder to start working on the project, we imported the subfolder. This was a workaround since it treated the subfolder like the root, so it functioned normally. In this folder, it also contained a git ignore file that could not be used since it was located in there. This meant that the node modules folder was also included to be committed back into the repository. In the majority of cases, it is not recommended to commit that folder, but little did we know what was happening.

           In the end, the Professor and another member managed to get a working copy sorted and uploaded to the master. Now it is structured with all the necessary files in the root and two other subfolders, one for backend and one for frontend. It is neat and easy to navigate, which meant that we would be able to easily pinpoint where new services and components can go. At this point, we don’t have to worry that making changes would risk breaking the builds that other members spent time working on. In the future, I will not let this situation happen again and will be more careful when structuring a project!

            During this sprint, I focused my efforts on creating a submission service. Currently, the intake form includes a submit button that only returns what the user has inputted in the form into a new page. I started using an Expressjs server, which has allowed me to get use simpler features to connect the main form with a local server. Eventually, the default url address should be directed to an actual server. In this current iteration of the intake form, it sends the array to the localhost at port 3000. By running both the server and the intake form in WebStorm and submitting a completed form. We can see that the array of data is now retrievable on the server, which can be seen in WebStorm’s terminal for the server. If everything goes smoothly we can most likely store the data into some form of non-volatile memory later on.


It was there, the whole time.

For the tenth and final week of reading, I chose to read the pattern, Use the Source. This pattern focuses on the problem that without the presence of good source code to study, practice, and emulate, you can’t get better, and you might continue developing bad habits you didn’t know you have. The solution provided is to find another person’s code and start reading them. This will enable you to learn how they wrote their code and understand the thought process that made that code. The recommendation includes examining open source projects and examining them for why they work in such a way. Also, to attempt and refactor codebases to understand the decisions programmers make and why they didn’t choose a different way. This process also leads to why there is appreciation for code reviews and pair programming. Having other people read your code, you read theirs, everyone can learn from each other. Allowing yourself to get a feel for good and bad code, you can develop a better understanding of yourself and how to improve.

This pattern is interesting because I never thought about using open source projects as a way of learning. I always took open source projects as a way of getting things from the community and as a way of contributing back to the project. However, using it as a way of reading well maintained code, reading practice, and understanding the thought process is a creative way of using publicly available projects.

This pattern is also useful because once you have seen the code, you might remember it for later as the code is not textbook examples. Examining, dissecting, and understanding code from real world projects allow you to see more, retain more, and most likely apply it in your own code later on.

The pattern has caused me to change the way I think about my intended profession because there are many different ways of improving yourself as a software developer. Being on the look out for readily available information and tools and being creative with the resources you do have access to can make a difference. As such, this pattern is incredibly helpful at showing that sometimes resources for learning can be right in front of you, you just weren’t creative enough to know it was there from the start.

Sprint Retrospective – Round Three

A reflection on what I learned from this week’s activities is that sometimes it’s best to restart. Our initial two sprints brought us up to a point where the current delivery is usable but could not be built upon. We had trouble trying to incorporate features from each of our own work loads that was divided in Trello. The main issue from the scrapped delivery is that it is written in Java and missing fundamental components that would make it difficult to create a webpage with. As such, the problem resolved after deciding to focus our efforts on Angular and using it’s features to make our lives easier.

Another lesson learned from this week’s activities is that having more than one repository between two GitHub and GitLab is a nightmare. It was a mix between each of the members uploading to our own repositories to share mockups of things we have created during the sprint. This choice is backed by us not feeling up to upload mockups directly to the repository made by the professor since we weren’t “feeling ready” yet.  Then there is the issue with having two different food pantry repositories which further confused everyone. However, this issue was eventually resolved when the professor and some students came up with another idea for handling the repositories. The new system creates a fork from the main project to the class repository. There are a couple other things mentioned about incorporating “stories” using this setup that I have yet to fully understand.

The third lesson learned from this week’s activities, is that it is very easy to get lost and sidetrack from the main goal. This lesson is mainly for myself as I was working on the database but took me an entire sprint to realize that I was working on the wrong portion of the project that was unneeded at the moment. Focusing unnecessary resources towards a feature that should be left for later. The other members were focused on the intake form and had created the front-end of it but needed a place to store the information later on. This is the area I should have tackled, in which our members would have been working in unison.

During this sprint, I focused my efforts on mainly establishing a connection to the SQLite database created from the previous sprint with the current project. Using JAVA and the available JDBC library found on the web, I was able to successfully connect to the database. However, when it came to transfer what I learned into the main project we were working on gave plenty of errors. There were missing libraries and many unused and preplanned files that needed deletion. Although this was a problem, the next problem is mentioned earlier in the blog. We needed a clean slate to work with since the project was in an unworkable state. After we got back to the point where we were in JAVA, now in Angular, I had to find a new way to get the SQLite database to work in Angular. Now that we are back on track, I can see where the project is likely headed!



Record, Revisit, Retain

For the ninth week’s reading, I chose to read the pattern, Record What You Learn. The problem this pattern addresses is keeping a journal or history of what you learned but not casting it aside. It suggests that a journal, personal wiki, or blog of lessons can help you in the future. This can be either for mentoring purposes, or a source of information for yourself and others. However, the biggest trap stated is that you will write down the lesson and forgetting them. The next step of writing them down is to revisit them regularly and review what you have written down. Eventually, the outcome is that you will achieve an accurate self-assessment of what you actually know. An example of a successful journal is about a guy named Dave who kept quotes that shaped his learning and eventually totaled over 500 quotes. With this he was able to share it with others and was helpful when he started writing articles and this book in particular!

What I found useful about this article is that it made me do a self-assessment on the spot about how I’m currently retaining information from school. Notes, projects, presentations, and papers are all evidence that I have been actively involved in my learning. However, once the course has finished, all those notes, papers, projects, and presentations are forever locked away in my drive, closet, or thrown away. Valuable information that could be useful in the future is now stacking up somewhere that can’t be maintained in a practical way.

What I found interesting about this article is the portion of the personal wiki. I did not know that you could create a personal wiki and it answered a question along the way. The question is what happens if there is something you learned but don’t want to share publicly. As such, you could have private and public records with no issues. This sparked an interest for myself, as I need a breakable toy to mess around with and learn but didn’t want to create a blog from scratch to do the job. Overall, this pattern is meaningful as it’s a good place to start if you don’t have anywhere to begin.

Balancing solo-work and team-work

For the eighth week’s reading, I chose to read the pattern, Confront Your Ignorance. This pattern takes on the problem that you have gaps in your skillset that is needed for the job. These could be tools or techniques that you are already expected to know but you don’t and need a place to begin. The solution to this problem is custom to the person in need, there are many different ways to start. Two ways suggested are trying to start with introductory material or jumping straight into hands on learning. It is mentioned that even if you are doing this in private to learn and apply it in the workspace, there are issues that could arise. One is that you are using work project experience for private projects solely for yourself and not the team. Another would be that the team will not be able to help you, learn with you, or help you along the way. As an apprentice, you should be learning in public where others can see the way you work.

The interesting part of this pattern is about the negative side effects from learning in private. When you work as a team, it is expected that you fail together, learn together, and learn from each other. By working solo and focused on improving your own performance, you are neglecting your team in the process. Another negative would be that you chose to implement a feature or system that has already been created elsewhere. By implementing your own version of it, the other members of your team are now required to learn from you about the system. This is a drawback and should be carefully considered when valuing your company’s resources and teammates workload.

This pattern has caused the way I think about my intended profession because there is a need for balance in terms of solo and team activity. If the workload shifts towards solo, then you aren’t benefiting your community. But if the workload shifts towards the team, then you are over reliant on the team. What I learned is that, you must know how to balance your learning such that everyone is winning in the end.

Can you walk the walk?

For the seventh week’s reading, I chose to read the pattern, Concrete Skills. This pattern focused on the problem where you want to work on a talented team to learn more and improve yourself. However, the risk of hiring someone who may not contribute directly to the work and could be a baggage is too high. The solution to this is to “acquire and maintain” concrete skills. Examples of these concrete skills are as listed “writing build files in various popular languages, knowledge of various popular open source frameworks like Hibernate and Struts, basic web design, JavaScript, and the standard libraries in your language of choice”. The objective of these concrete skills is to present enough understanding of what you can do on day one. This will provide a chance where your likelihood of being hired is increased. However, when you are hired, you do not have to repeat the steps in the future because you likely have built a reputation and portfolio with your current job. As such, credibility has been established and should prove to future teams that you can be useful on day one.

What I found interesting about this pattern is that it mentions “getting past crude HR filters and managers who construct teams by playing buzzword bingo”. This relates to stories I heard of HR or managers who do not have enough knowledge to do the hiring but is placed in a position to do so. As such, they would deploy tricks and systems, or “filters” in order to find the people they need. Another interesting point brought up by this pattern is the action provided at the bottom. It states that we should note discrete skills that could be useful right away for the team that you want to join. I do believe this is a good strategy to be on top of knowing what skills you can bring to the table.

This pattern has not caused me to change the way I think about the intended profession because this also useful for other professions. The process of hiring people onto a team is always a risk in one way or another. Systems are brought into place because they want to avoid issues off the bat from a new hire, as such you have to demonstrate that you can do the job they expect of you.