Software Capstone Sprint #2 Retrospective

During the second sprint of my software development capstone class, it had a very unique feel to it for various reasons. One of the reasons on why it had a unique feel to it is because my team and I had to create some of our own side tasks in addition to the ones that we were assigned. Considering that this is the second sprint, it didn’t contain that many tasks to do besides getting use to some new applications that were introduced such as Balsamiq which is a nice tool provided by AMPATH.

What I learned in this week’s sprint was learning how to use Balsamiq, learned the fundamentals on how an offline module works, and learned how to map the node paths to understand how the AMPATH server communicates to a router module to fetch patient data. Learning how to map the node paths from the AMPATH code was one of the side tasks that I my team and I wanted to do because we felt that it would put the team as well as the rest of the class in a good position to prepare for what could come next in the upcoming sprints. Keeping that in mind, I think that this portion of work that my team and I are doing can benefit the other teams in the class because the ideas or information that my team and I come up with might be useful to other teams and vice-versa.  Looking back on how I’ve learned these things with my team, I think I did a great job and I don’t see anyway to approach this differently.

The team performance was good and the CATME Team Evaluation in my opinion was accurate.  Everyone in the group participated in all the tasks that were assigned for them to do. My performance fell under the category of completing a fair share of work, if not a little more. I assigned my personal task to be making sure that the team trello board was up to date on what tasks each person should be doing. That will be my personal task moving forward with the upcoming sprints in addition to other tasks assigned to me. As far as it goes for my teammates, they all did well. Rick and Jason contributed heavily in trying to understand the node paths in the AMPATH code. Jeremiah reminded the group to not forget to do the standups that we needed to do on Mondays, Wednesdays, and Fridays. Everyone contributed to the work fairly and I think we established an organized way to keep track on what person is doing, and making sure that they are doing something. I don’t we could’ve approached this differently.

The tasks the got done was reading the user stories for offline modules, and checking out the node paths. The one thing that I would consider that didn’t get done was figuring out the node paths. Although my teammates and I did find how the server communicates and we also got a brief idea on how it talks to the router module, I would consider this task an ongoing or work in progress. The steps that we took to approach this task was that first, we tried to search for patients, but no data returned to us. So that made us think that there might be a connection issue to the routing server in the code. In order to test that theory, we tried to locate the router module in the code, and from that point we made that our task in understanding how the communication between server and router module worked to fetch the data within a database provided by AMPATH. We succeeded in getting ideas from dissecting the code and drew a path diagram in Balsamiq on how might the communication takes place. I would say that we failed in a sense that we couldn’t fully figure how it actually communicates within the time given in this sprint. We chose this course of action by trying to fetch patient data.

Overall, the team and I were satisfied with this sprint. One thing that improved from the last sprint was communication between team members. Everyone knew what to do and everyone knew what each person was doing which promoted quality work.

 

 

Emptying the Cup: The Deep End

In this Apprenticeship pattern “Emptying the Cup: The Deep End”, it explains on how you as a developer can further your development skills by taking on challenges that may or may not involve risks. Even though there may not be risks that can affect your career as a software developer, it may cause you to fail the challenge or objective you are trying to accomplish. Of course in any industry of work that you may wish to advance or climb the ladder in, you have to tackle on bigger tasks to show that you have the skills and mindset to be in a bigger and better position than the one you are currently in. However, failure can result in the process. The Apprenticeship pattern “The Deep End”, highlights that failure is normal when taking on challenges.

“This has risks. If you get it wrong and end up over your head you could drown. Thankfully there are many places in IT where you can take risks without destroying your career if you fail. Risks are opportunities seen through the half-shut eyes of fear. This doesn’t mean lying on your resume to get a job you can’t do, nor does it mean tackling challenges without adequate preparation. Instead, it means taking that promotion or foreign assignment when it’s offered, even if the very real possibility of failure is staring you in the face. Being prepared to fail and recovering from that failure opens doors that the timid will never see.”

Drowning in this context means failure and I completely agree with this idea because as an individual, I learn best by failing and making mistakes. At times, I can be scared to fail but I know deep down it is the best way for me to learn. This pattern also reminded me that feeling fear is okay when you I think failure is staring me right in the face because the after effects of failure is more of a gain for me when taking on a challenge than being successful on a smaller, simple task. After I fail a challenge, I reevaluate what I did wrong so I can approach it differently the next time I take that same challenge head on. This concept of taking on “The Deep End” isn’t only important in Software Development but it can be applied in any workplace.

 

Emptying the Cup: Concrete Skills

In this section of the Apprenticeship Patterns, the term “concrete skills” was introduced. It gives us an overview of why having certain concrete skills are necessary to have, especially when you, as an apprentice, will start developing your craft in the software development team. For example, a concrete skill can be your “First Language”, where you have prior knowledge and skills on understanding the programming language and knowing how to implement it in an IDE.

“Having knowledge is not the same as having the skill and practical ability to apply that knowledge to create software applications.”

I found this idea very useful and I completely agree with it because a developer who has adequate or substantial knowledge in software development has no value in their team if they do not know how to implement their knowledge in their craft. Therefore, the develop has no value in their team, and is nothing more than a dud in the team.

“The point is that you will often require hiring managers to take a leap of faith in choosing you. Concrete skills (which are ideally discrete enough that you can bring toy implementations to an interview) allow you to meet them halfway. The concrete skills you possess are your answer to the question: “If we hire you today, what can you do on Monday morning that will benefit us?” A deep understanding of ‘Your First Language’ will help establish your credibility and should prove to be extremely useful to your team.”

This idea supports that programming languages can be an effective concrete skill to have. Programming Languages, however, are not the only concrete skills that developers may need to have. Team management, communication, and organization skills are also necessary to have in order to have an efficient and cohesive team.

Reading this Apprenticeship Pattern made me think about the development capstone class because it made me evaluate myself and my team members on where we stand in acquiring our concrete skills. Within the past couple weeks, I’ve been trying to get use to Angular by doing more of the Angular tutorials so I can be well equipped on that knowledge on how use Angular. I think that would be a great task for me to do so in case if my teammates need help on Angular, I can show them, which is how I can be become a valuable asset to the team and our success.

Software Capstone Sprint #1 Retrospective

During the first sprint of my software development capstone, it mainly consisted of setup tasks which would aid into the upcoming sprints that are later to come. What I’ve learned was how to adapt to the team that I’ve been set up with, using Angular through the webstorm IDE, accessing the AMPATH server, briefly using trello, using git commands, communicating on the Slack channel, managing the Team’s git repository, and experiencing of what it’s like to work in a software development environment. Looking back on how I’ve learned all of these things, what I would’ve done differently is that I would communicate to my teammates a little bit more through the slack channel because there would be times where my teammates would often lose sight on what I was doing. They could only know through the standups that we do every Monday, Wednesday and Friday during the sprints. That would be one of the main areas that I could’ve improved on and would’ve done differently.

Out of these things that I’ve learned through this first sprint, they could all be applied in upcoming situations. Communication will always be an ongoing action to take especially working in a team since everyone needs to be up to date on each others work. Angular will probably be in constant use as well as the Slack channel and possibly trello. Acessing the AMPATH server will probably be a must in all sprints as well because the team and I will be submitting code to the server.

On a scale of one to ten, where ten is the highest, the team’s effectiveness throughout this sprint would be an eight and a half. There were some instances where my team members Rick, Jason, Jeremiah, and myself all had trouble getting access to the AMPATH server. Some of us had to install some dependencies, whereas some of us had to update the webstorm IDE. There was a case where Rick had inputted the wrong command into the terminal in the webstorm IDE to connect to the AMPATH server. At first we thought there could be something wrong with his code, which led to spending an entire class on figuring out what went wrong. That’s when we knew at the end that he had entered the wrong command. After all of the team members had successfully accessed the server’s login menu, it was smooth sailing from there.

As an individual throughout working in this team, I felt I was competent enough to do the work that was assigned to me. Besides going through some trouble with accessing the server, the process of trial and error helped me learn new things, which led me to teach my teammates things that I encountered along the way. Besides delivering quality work, I tried to be the individual within the group that made the atmosphere more enjoyable, especially in group discussions about our current tasks. What we will be doing differently moving forward is that we would organize our tasks a lot better through the concepts of the trello board by organizing and assigning tasks to each individual team member. That way, it allows everyone to keep track on who is doing what.

What was done during the week was we established a connection to the AMPATH server, created a trello board for the team, practiced some angular tutorials, and managed a github repository. As said earlier we tried many things to fix and gain access to the AMPATH server login screen through using different commands, updating webstorm and installing dependencies. We tried the command “npm run server” or “npm start” in the terminal in webstorm, and that worked. The command that failed back in Rick’s situation was “ng serve”. There were also some instances where Jeremiah and I had to uninstall node.js and install it again, which was one of the course of actions we took when nothing else worked.

Overall, the first sprint was a learning experience for myself and the others. Currently, we are trying to figure out a better way to manage our github repository that allows an easier way to do pull requests. My teammates and will come up with something later on.

Emptying the Cup: Unleash Your Enthusiasm

In this portion of the Individual Apprenticeship Patterns, it gives an overview about how the new coming of an apprentice can impact a development team that is filled with well-experienced craftsmen or developers. Apprentices by their nature are new, and inexperienced first hand, and therefore they are open to learn ideas and techniques used by the craftsmen around them. Assuming that most of the experienced craftsmen have 10-20 years experience, they are unable to further their skills because their only primary concern is to just get the job done or delivering the next project.  In order for a development team to improve its dynamics with new ideas and techniques, the apprentice can be one of the main components to improve or repair the team’s passion and enthusiasm.

“Most teams are not hyper-passionate or overly enthusiastic about technology. Predictably, they are focused on delivering the next project or improving on the aspects of the development life cycle that are causing them pain. Therefore, enthusiastic apprentices can often succumb to the urge to fly under the radar.”

The quote struck out to me because it shows the apprentices can give in or succumb to the ways of the experienced developers. As an individual, I want to be the type of person to bring enthusiasm to the team and to allow a flow of passion and excitement into the team. To me, maintaining a positive vibe and atmosphere allows everyone in the team to communicate effectively and consistently.

“On a team that is open to the excitement and contributions of an apprentice, you will provide some unique qualities that more experienced developers rely upon, such as unfettered imagination and enthusiasm. This is the time in your career when it makes the most sense to take risks and speak your mind. You have very little to lose. Your ideas and passions will add intelligence and diversity to your team.”

I found this quote extremely useful because it supports my idea that as a team member, having a passion about the work environment or project can bring positive outcomes for the team, and good things will happen. I fully agree with this Apprenticeship pattern because it promotes an amusing and enjoyable atmosphere for every team member, which can be traced back through the conscious or subconscious actions of the apprentice.

Emptying the Cup: The White Belt

In this stage of the Apprenticeship patterns, it gives us an overall idea of what it’s like to be an apprentice. In terms of learning different programming languages, especially if its a new language, it will be hard to learn it because you have prior knowledge on the concepts of basic programming actions. According to the Apprenticeship patterns, “we have to be able to put aside our past experiences and preconceptions to allow new knowledge in. This is especially difficult when trying to learn your second programming language, because it is likely the first time that you have to sacrifice productivity in order to improve your skills.” When you think you are knowledgeable in programming languages, you are unable to take in the maximum depth of learning you are expected to take in as well as limit the ability to discover new possibilities.  To put this in the modern work place, team members will always have a certain level of competency in the work that they do. Pride will be one of the factors that may be an obstruction to the team unless each of them are able to allow themselves to unlearn what they learn in order to learn new things in case problems should arise in the future.

What I found interesting about this pattern was how the metaphor “white belt” was used.

“Wearing the white belt is based on the realization that while the black belt knows the way, the white belt has no choice but to learn the way.”

In my mind, I thought it made sense because as a true beginner, you know nothing at all to start off. To be taught at first, it is normal to think that the first way you learn would be the right way. At that point you allow yourself to learn, and therefore, you are able to discover possibilities you hadn’t known.

This Apprenticeship pattern was useful because it made me think of when I first learned my second programming language, which was Java. When I transitioned from C++, I thought learning Java wouldn’t be as hard as I thought it would. It ended up being harder because I wasn’t allowing myself to learn the full principles and rules of the language. I took shortcuts when I wasn’t suppose to, and I had to learn that the hard way as I struggled through learning it. Soon after, I took it step by step and allowed myself to learn it the right way.  I completely agree with this pattern because not only it applies to programming, but it can apply to anything you learn in life, and it starts by wearing that “white belt” first.

 

Apprenticeship Patterns: Chapter 2 Emptying the Cup

In Chapter 2 of the Apprenticeship patterns, this chapter provides an overview of how an apprentice starts out into his journey. The chapter is broken down into sections where Hoover and Oshineye layout the details of “Emptying the Cup.” Patterns about understanding your first language, wearing the White Belt, Unleashing Enthusiasm, acquiring concrete skills, exposing your ignorance in a specific technology, confronting that ignorance, taking a chance to dive in The Deep End, and Retreat into Competence are the patterns an apprentice will experience and go through.

One of the patterns that sparked my interest was First Language. In the beginning of this pattern, there was a quote that i strongly agreed with. “By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race.[…T]he technical terms of any profession or trade are incomprehensible to those who have never been trained to use them. But this is not because they are difficult in themselves. On the contrary they have invariably been introduced to make things easy.” This quote from Alfred North Whitehead reminded me on concepts of effective and efficient programming techniques. One of the concepts of effective programming techniques was the acronym YAGNI, which stands for “You Ain’t Gonna Need It.” To be an effective programmer, you need to manage your time wisely and devote that time to parts of your code that are going to matter the most. There’s no need to waste time adding things to your code that aren’t going to matter. It’s the same thing that goes for the brain. If you remove all the unnecessary thoughts in the mind, it will provide more room for mental power to make things easy when you work and conduct your tasks. I feel like that is the message that is being sent by Whitehead and why I think this quote was placed into this section of the First Language.  I find this chapter to be very useful and I agree, especially as a programmer, that efficiency in the workplace is important and that this chapter and pattern highlights that aspect.

Apprenticeship Patterns Chapter 1

“Apprenticeship makes a difference because it instills a lifelong passion to master the craft. It instills a passion for perpetual learning and, in the process, enables the apprentice to become a great developer.” – Pete McBreen

I do agree with this statement that was at the beginning of the chapter. As an individual, whenever I hear the word “Apprentice”, I always wonder and think about the “Master” because that is who the apprentice learns from. After reading through this chapter, I tried to tie all the concepts back to the title of the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. An apprentice should always try to learn and understand the concepts that the master is trying to teach. Understanding and learning the concepts is one thing. Learning how to implement and use the concepts is another. The techniques that you learn from a master can sometimes, if not most times, be found found in textbooks or they can’t be basically self-taught. Every master can have different styles, which is why a “master” is very valuable and special in a sense. To me, that is an Apprentice and Master relationship. When the apprentice is trying to perfect their craft with the aid of their master, it instills something very special within the apprentice’s work and makes them have the desire to want to learn and create more. This quote by McBreen is very important to me and makes sense to me the most. To relate it to myself, I feel that the Master is the contents of which I am trying to learn, and the Apprentice or Journeyman is myself.

There is a quote that also sparked my interest because it is a statement that I fully acknowledge. “One of the lessons we’ve learned from the Agile development movement is that just telling people to do things doesn’t create lasting or sustainable change. When the people you’ve advised encounter a situation that isn’t covered by the rules, they’re lost. However, if those same people have imbibed the values that underpin the rules, they can come up with new rules to fit any situation. Our goal here is not simply to hand people a rule book, but to give them the ability to create new practices for new contexts, which in turn drives the discipline of software development forward.” This supports the thought of critical thinking in a sense that thinking outside of the rules in order to create new ones is the foundation of continuing the evolution of software development. If developers encounter a situation that certain rules do not cover and they become lost, software development cannot progress forward.

As I am currently aspiring to become a future video game developer, I expect that there are going to be new rules that are going to be created constantly. I know that I am going to learn and to develop certain “crafts” to be very efficient in that environment of work because there will be many things to adapt to. As Pete McBreen points out, there are many developers out there today in the field. The important question is are there enough “good” ones? When I head out there in the field, I would want to be recognized as one of those “good” developers.

 

Code Review: What is it and Why is it Important?

Link to blog: http://thinkapps.com/blog/development/what-is-code-review/

In this blog written by Dario Macchi, Macchi explains what is code review and why it necessary to do. He identifies what it is, its purpose, What is peer review, what do peer reviewers look for, what is an external review, what do external reviewers look for, and a few scenarios on what should code reviewers do if something goes wrong or if something is missed within the the code review process.

Code Review: is systematic examination … of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills.”

Purpose: to validate the design and implementation of features within the code. Macchi identifies that there are two levels of code Review. These are the peer review and the external review levels.

Peer Review:  focused on functionality, design, implementation, and usefulness of proposed fixes for stated problems. Macchi explains why it is neccessary to perform a peer review within his company because in his company, they expect developers to talk to each other about their design intentions and receive feedback throughout the design and implementation process. Macchi’s real life experience gives us an example about the working field of software development and testing and how peer review is necessary. Peer Reviewers look for feature completion, potential side effects, readability and maintenance, consistency, performance, exception handling, simplicity, the reuse of existing code, and test cases.

External Review: addresses different issues and focuses on how to increase code quality, promote the best practices, and remove “code smells” or poorly written code. This review process looks at the quality of the code itself and its effects on the overall project. External reviewers look for readability and maintenance, coding style, and code smells.

A scenario that Macchi illustrates is “What is an external reviewer misses something?” The answer he gives is that we do not expect the external reviewer to make everything perfect. There is always something that would be missed. In this case, it is better to have more than one external reviewer. Another set of eyes always helps.

I chose this blog because I wanted to know the right process on reviewing code. I also chose this blog because it relates to my Software Quality Assurance and Testing Class since I was given an assignment to review code with my group of classmates which emulates the peer and external review process and emulates the real life workplace. Macchi definitely outlines the aspects of code review very well when he identified the two levels which were peer review and external review. Knowing code reviews will definitely help me apply myself in the future to many software development and testing jobs as well as my video game development career because there is always a 100% chance that I will review code with a team of other programmers no matter where I work at, especially when it comes to creating video gaming software.