Sprint #6 Retrospective

During this Sprint, my team and I tried to complete as much as we could since we are coming to an end in the semester. We wanted to at least give JJ and the AMPATH people some sort of workable interface for our offline data capture service. Throughout the process of finishing and having a workable interface, the team and I decided to focus all of our attention on that aspect, aside from the encryption service that I was trying to discuss with the encryption team involving the javascript implementation crypto.js.

Some tasks that we did during the week that helped lead us to establishing the offline data capture service interface were:

  • Help ensure GUI code is compatible with any offline-capturing abilities we implement when the user is online and vice versa.
  • Create balsamiq diagrams outlining current and anticipated implementations of offline-capturing the OpenMRS / ETL data.
  • Ensure all new components, GUIs, etc comply with basic AMPATH CSS styles, overall look and coding convention.
  • Code the offline GUI based on the help and input from Jerry and other teammates.
  • Write/maintain tests for our implementations so they are always as current as possible.
  • Seek help from the AMPATH development team if any of us hit a roadblock concerning implementation.
  • Offer suggestions to other teams based on our overall process, so that all teams’ implementations can work together as smoothly as possible.
  • Touch base with all teams (encryption, offline-storage, and login) regarding their overall progress.
  • Develop high-level idea of a Doctor/Provider object so we can consider if it is worth implementation.
  • Develop mock diagram where a “Doctor/Provider” can pick and choose what patients to sync.

The above tasks were what was tried and attempted. What was done and completed were the establishment of the Doctor/Provider object, and the mock diagram. For the GUI task, we had to communicate with JJ a lot. Due to the amount of time the team had, we had a feeling that there wouldn’t be enough time to create a perfect GUI, even though JJ wanted one. Midway through the sprint, we sent JJ our progress on what we did so far for the offline data capture service through a walk-through video that we shared on the slack channel. JJ then understood where were at with the progress and we concluded that it was okay to work towards establishing an interface where the user can clearly see if he is offline/online along with the data. That was one of the tasks that we had approach differently and adjusted to.

As a team, we learned to make a major adjustment to our task during this sprint. We knew that time was a concern, and what the people at AMPATH and JJ were expecting to get, which was the new offline GUI, seemed to be too much. We wanted to at least deliver something to them that at least worked, which is why we moved away from creating the new GUI. From this situation, this could be applied in real life software development environments because there will come times where I would have to adjust my tasks to deliver something that the customer wants, even if it isn’t 100% of what they want it to be, it will perform the same functions of what they want it to do.

The team’s performance during this sprint was above above average. Everyone contributed evenly or more than an adequate effort throughout this sprint. Communication was very effective between each member and between our team and AMPATH. As an individual, I performed average during this sprint. I mainly tried to talk to the other teams, trying to get some info on their status. The only team that we communicated to more than others was the offline data storage team, and we began to work alongside with them since our tasks were similar to theirs. I also tried to help find several components in the AMPATH code for which JJ wanted the interface to display such such as genral patient data, vitals, lab results, and HIV summaries.

Overall, the team worked diligently and we wouldn’t have proceeded in any other way. We will try to have our offline interface working, completed and delivered hopefully by the end of this next half sprint.

Software Development Capstone Sprint #5 Retrospective

During this sprint in my software development capstone class, my team and I tried to make some progress on establishing our offline data capture service. Before creating our tasks, we organized our team’s trello board to be a bit better. We changed the layout of our board by creating different columns that were categorized by our names to indicate who was in charge of doing a specific task that was assigned to them. We did this because it could make us as team to better understand who was doing what, and what was currently worked on in this sprint.

The team and I attempted to find out more ideas from the people at AMPATH through the communication with Jonathan Dick. We felt that we needed to get some ideas to further progress at our offline data capture or else we wouldn’t know what to do during this sprint. One question that I had asked to JD pertained to a GUI, which he wanted that indicates and separates offline data from the online data through our service. We are still currently figuring out on how to create the GUI. Other tasks that we attempted were:

  • If dealing with CORS issues, create a desktop shortcut loading an instance of Chrome disabling web security.
  • Create balsamiq diagrams outlining current and anticipated implementations of offline-capturing the OpenMRS / ETL data.
  • Write tests for our implementations.
  • Design the HTML part of an offline component that will be used for our GUI. Should be similar to the layout of the AMPATH Patient Search Component.
  • Collaborate with the encryption team regarding the process of how our captured data ought to be encrypted.
  • Touch base with all teams (encryption, offline-storage, and login) regarding their overall progress.
  • Create a mock diagram in Balsamiq illustrating an idea of a GUI that presents the captured data in a meaningful way.
  • Develop mock diagram in Balsamiq where a “Doctor/Provider” can pick and choose what patients to sync.

All of these tasks are still ongoing, leading into the next sprint. I felt that we were unable to complete any of these tasks within this sprint because we spent most of the time asking questions. I would admit that there were times where we were lost because we weren’t  communicating enough to JD. However, one task that we got done was:

  • Get ALL patients in the database (not just those with “test” in the name). Store each patient results into an array, then iterate through it to store each into separate files in PouchDB.

What we learned from attempting these tasks was that it taught us to constantly communicate with AMPATH to develop a smooth transition from task to task so we don’t get stuck and waste time on what to do next.  Communicating with AMPATH and asking questions to them will help us develop ideas on how to proceed with a task to validate what we are doing is what the people at AMPATH and JD wants. This was the main thing we learned from our mistake. This can be applied in other situations because in the software development career, communication is one of the most important things to do for this particular reason. If there is not constant communication, whether it be to your teammates or anyone in the workplace, work can become difficult and you can become unaware of what to do, which can further delay the project or task from getting done.

The effort that my team put into this sprint was sufficient despite the incomplete tasks. Everyone still tried to attempt at something even though we were still stuck on how JD and the people at AMPATH wanted our Offline Data Capture service to look like. For this sprint as an individual I mainly tried to still gather ideas and find a suitable encryption implementation for the AMPATH code and I think that using crypto.js wouldn’t work efficiently, so I decided to keep on researching. I also talked to the encryption team and found out that they ran into some impediments as well on developing their encryption service. Moving forward, my team and I need to communicate more effectively with the other teams as well as with JD and AMPATH. Doing this will help us work better.

Walking the Long Road: Draw Your Own Map

In this Apprenticeship Pattern “Draw Your Own Map”, it explains the importance about creating and managing your career path once you are exposed in the software development environment. A couple of key points that the pattern states are:

  1. Your manager, professors, or colleagues are not in charge of where you position your career as a software developer.
  2. Your are responsible for your destination and goals.

These couple of points emphasizes the concept of a software developer’s individuality. It is true that within the software development field, everyone is a programmer and creates many different types of software. It is up to you as an individual to take steps towards what you aspire to do and become within this field of development. One quote that stood out to me was this one below that talks about your vision of goals versus the employer’s vision for you.

“If you find that your vision of yourself is not in accord with your employer’s vision for you, and there doesn’t seem to be a way to reconcile the differences, examine other opportunities to see if they’re heading in the desired direction. Remember, there isn’t one single path that all apprentices follow. Instead, successful apprentices follow paths that share a certain family resemblance. These resemblances do not happen because apprentices are inexorably shepherded into making the same decisions by their mentors. They happen because each apprentice, consciously or not, chooses their route through life based on an overlapping set of values.”

I agree with this idea because it seems like it will be the most realistic to me once I start working for a company that may not have the same vision for my career as I do. This idea also will allow me to change the way on how I would manage my goals and career paths while working in the field. I will continuously plan and weigh options that would be available to me out there in the software development field since there are many companies and employers to work for. It goes back to the concept of leaving your current job for a better one because it does not meet your intended needs or it doesn’t help you grow in the field. For me, I’d like to work for a place that respects my needs and aspirations. As a future video game developer, I want to have that luxury of being able to grow into a successful video game developer and there would be nothing more  important than that.


Software Development Capstone Sprint 4 Retrospective

During the fourth sprint of our Software Development Capstone class, my team and I made some progress towards fulfilling our primary task of creating an offline data capture service. Some tasks that we created in order to reach towards the offline data capture were to figure out and introduce ourselves to pouch-db and how it could be implemented with Angular and the AMPATH code, getting pouch-db to work and compile with the AMPATH code, and researching cryptojs and finding out if it would work well with pouchdb to establish an encryption service with the offline data capture service. We manage to tackle these tasks that we created because other teams had researched cryptojs and pouch-db, so we felt that we had to do the same by introducing and exposing ourselves to these JavaScript implementations.

When we attempted these tasks, we managed to successfully learn about pouch-db and got some ideas about how it would work with the AMPATH code. Once we gathered all of our ideas together during our meetings and communication on the team’s slack channel, we started to tinker with the code itself and installed pouch-db within Webstorm’s terminal so that the dependencies can be present within the code. At first, we had trouble getting pouch-db to work with the AMPATH code because we kept getting compile errors. We assumed that the errors were coming from the packages that were installed from the pouch-db installation, which happened to be true. So, our team member Jason, stepped up and tried to find out how to troubleshoot this issue. He went and found how to properly install pouch-db since we had initially installed it the wrong way. We had to clone a clean copy of the AMPATH code from our own repository and make a new project from that copy. Once that was done, we had to remove the “Package-Lock.json” component from the code, then install it. That component happened to be the main cause of the problem. It was smooth sailing from there, and we successfully connected to the AMPATH server and log into it without any issues.

For crypto-js, we are still researching it and is considered an ongoing task. However, since my team and I did not come up with any ideas with the implementation of crypto-js in our offline data capture service, my team and I can categorized this task as a failed task for this sprint. Our goal is to get some ideas on crypto-js and implement it successfully by the end of the next sprint.

My team and I learned a substantial amount from this sprint, especially about the implementation of pouch-db. Despite the problems that we had with it initially, we overcame that problem through effective researching and communication within this team. I can’t think of any way to approach it differently because I’ve seen that with this group, we learn most effectively through trial and error. I felt that we researched pouch-db the best we could’ve done and successfully implemented it despite of the first compile error we ran into. This situation could be applied in other situations with any software development workplace. Working through trial and error is normal with this type of work and learning to overcome issues that may arise is a daily obstacle for developers such as myself, so I feel that this obstacle that we had with pouch-db was a great learning experience.

I feel that my team and I were very productive throughout this sprint. As an individual I had done my fair share of work and expected good quality from everyone. I mainly researched articles about pouch-db and crypto-js, and communicated the information that I found out to my teammates during our sprint meetings. For everyone else, they did wonderful. Jeremiah did his job with participating in team meetings and communicating over slack to remind each of us to do our standups. Rick helped gathered ideas for the code itself. Jason did the most work with the code and was the main person to work directly with AMPATH in getting ideas from them and at the same time getting pouch-db to work.

Overall, I’d say this sprint was very successful.


Walking the Long Road: Nurture Your Passion

In this Apprenticeship Pattern “Nurture Your Passion”, it explains the the importance of your passion as a software developer and how it can be exposed to situations or circumstances that can affect to maintain that passion. This pattern illustrates various ways to protect and keep that passion healthy as possible in order to prolong the enjoyment of being a software developer such as:

  1. Work on what you like.
  2. Join a local or study group that enjoys and focuses on the same things that you enjoy or want to learn more about.
  3. Read books that can expand your view of the field.
  4. Create your own path or move into an organization where your needs, asprirations, and goals can come to fruition.

“Paul Graham said, “The key to being a great hacker may be to work on what you like…. To do something well you have to love it. So to the extent that you can preserve hacking as something you love, you’re likely to do it well.”

This statement by Paul Graham was very interesting and useful to me because for me as an individual, I produce the best work when I love and enjoy what I do. There have been some instances of my life where I would not produce my best work where my state of mind does not like what I am currently doing, whether it be a class that I am taking at school or a part time job.

“To become a journeyman, you will need to have a passion for software craftsmanship. Unfortunately, your daily activities often work to diminish this passion. You might be faced with demoralizing corporate hierarchies, project death marches, abusive managers, or cynical colleagues. It’s hard for your passion to grow when exposed to such hostile conditions, but there are some basic actions you can take to sustain it.”

This is another statement that I found useful and will help me in my intended career because I understand at the end of the day, work is work, and there will always be times where deadlines, corporate needs, managers and co-workers will stress me out, which will lead to a decrease in my passion for software development, particularly video game development. However, the actions that I’ll take will help reinforce my passion to sustain the harsh natures of the work environment and to prolong my love to hone my craft.

Walking the Long Road: Sustainable Motivations

In this Apprenticeship Pattern “Sustainable Motivations”, it explains on how to sustain your motivation as a software developer through walking “the long road.” This pattern gave very good examples in situations where a software developer can have decreased motivation within their state of mind based on what they are currently doing or have recently endured, whether it be from a project for a customer, or in general, life at work. Some aspects that this pattern exemplified was the balance between being happy at what you do as a software developer, honing your skills and craft, and the amount you are getting paid to be financially well off.

At one point in the pattern, it gave very good examples that illustrate the point that there will be times as a software developer where you question your commitment to honing your craft or your profession.

“You hate your programming job and you’re motivated primarily by money. You find yourself focusing on climbing the corporate ladder over honing your craftsmanship. But you are also motivated by your reputation as a technologist, and this allows you to endure long enough for your job situation to improve.”

“You’re motivated primarily by your enjoyment of programming, but you’ve had a few months when you can’t feel the love. You are seriously considering abandoning the profession. Fortunately, you are also motivated by money, and you think that programming is your best option financially right now. You stick it out for the money and eventually your love for programming returns.”

I can picture myself being in these situations because of my concern for getting a well paid job. I know for a fact that money helps my motivation, however at the same time, I want to do what I love in the software development field, particular video game programming and development. In my mind, there will come times when it will be tedious and difficult while working, but with any job or career, work is work, and there can be times where I know I’ll face hardships and I will overcome them. Loving for what I do in my career will be the main reason for the longevity of my video game development career, and I’ve always known that since when I was a kid, I’ve had a passion for video games.  This pattern has opened my thinking on this particular career path and I agree with what this pattern has taught me about sustaining my motivation as a software developer.


Walking the Long Road: Craft Over Art

In this Apprenticeship Pattern “Craft Over Art”, it explains the relationship between the craft and the art of a craftsmen’s work. As an apprentice, it is important to understand how much of an impact both aspects have for the work that they produce for their customer. In the software development field, most of the work that you would produce would be for the customer or client that requests the product. With this being said, the customer or client that requests the product will have certain specifications that they want you, the craftsmen, to make, or they could ask for you to make a product that is useful for them.

“Craftsmanship is built upon strong relationships. Focus on delivering value to your customer over advancing your own self-interests. As a craftsman you are primarily building something that serves the needs of others, not indulging in artistic expression. After all, there’s no such thing as a starving craftsman. As our friend Laurent Bossavit put it: ‘For a craftsman to starve is a failure; he’s supposed to earn a living at his craft’. You need to do your best work in ways that place the interests of your customers over your desire to display skill or pad your resume, while still adhering to the minimum standards of competence provided by the software development community. Walking the Long Road means you must balance these conflicting demands. If you starve because you are too much of an artist and your creations are too beautiful to be delivered in the real world, then you have left the craft. If your desire to do beautiful work forces you out of professional software development and away from building useful things for real people, then you have left the craft.”

This idea of deciding craft over art is understandable and this idea stood out to me the most. The software that you make as a software developer must be useful to the customer, otherwise it is a meaningless piece of work.  It is okay to implement the special touches on your work once it has fulfilled its usefulness to the customer and their needs. However, it is not okay to primarily focus on the art aspect over the needs of the customer. You are called craftsmen for a reason, not an artist, and that’s how I view this pattern’s main idea. I completely agree with this pattern’s idea of craft over art and I feel that every software developer should consider the “craft” a priority over the “art” of their work first.

Software Capstone Sprint #3 Retrospective

During the third sprint of my software development capstone, my team and I were assigned the task to figure how an offline data capture service worked and how it would work with AMPATH’s patient database. The reason for creating the offline data capture service is to enable the retrieval of patient data while in an offline status. This is important because villages in Africa may not have internet connection, but AMPATH still wants to add additional information to their patient database.

One thing that I’ve learned from this week’s activities was how to an offline data capture service worked. To figure that out, my team and I also created other small tasks that aid in figuring out the offline data capture service. Another thing that I’ve learned how to do as an individual was creating tasks from scratch. In addition to our product owner assigning tasks to each group, my team and I discussed on how to approach towards the goal of establishing an offline data capture service.  This lead to the tasks that we created for us as a team to do. Throughout the entire process, I wouldn’t have done it any differently because everyone in the team, including myself, was productive in the way that we did things. This experience can be applied in real life situations, especially software development jobs. Since I want to be in the video game development industry, I’m going to have to learn how to approach the goals and objectives by creating my own small tasks that will lead up to completing the overall goal of a project.

What we did during the week was that we tried to create a balsamiq diagram which displays our idea on how an offline data capture operates. We also researched offline data capture services in Angular, and found more tutorials on them. We also checked out pouchdb and how it would be implemented in our offline data capture service and researched encryption to come up with ideas on how our offline data capture service would work cohesively with an encryption service that another team in our class was doing during this sprint. We succeeded in utilizing balsamiq to create our diagram of the offline data capture service, learned pouchdb, understood how an encryption service works, and successfully came up with ideas about how to interpret the offline data capture service by reading online articles and other resources.

The work quality for this sprint was adequate for all of us to do. From the past sprints up until this sprint, everyone contributed fairly if not more for some of us. I’d have to give a lot of credit to my teammates Rick, Jay, and Jerry as they helped me as well as the entire team on making sure everyone was on the same page. Jerry reminded the group about the standups. His contribution to the group has improved from the last sprint and I felt he communicated more in our meetings in class and on slack. Jay and Rick did an exceptional job of finding some resources about the offline data capture service and they both did well creating the diagram as well. What I did throughout this sprint was a lot of information retrieval which I shared as much as I could with my group about pouchdb, the encryption service, and about the offline data capture service. All of efforts played a huge role in getting us to where we are at with the offline data capture service right now as we are putting the pieces together with our diagram and our ongoing research.

Overall, creating the online data capture service is still an ongoing process. The team and I will still carry some tasks from this sprint onto the next sprint. A couple of these ongoing tasks include:

  1. Figuring out how pouchdb will work with Angular.
  2. Figuring out how encryption will work with our local storage system if we decide to work with local storage instead of pouchdb.

Walking the Long Road: The Long Road

In this Apprenticeship pattern “The Long Road”, it gives us an overview about “the journey” that an apprentice goes through to study, learn, and develop his own craft. Considering that there may be shortcuts towards mastering your craft, it always best to let the journey carry you as a developer because the little things you experience along the way will help you become better overall. Not only the experience is important, but it is also important to understand that there isn’t a literal “mastered” status for a developer where you stop learning or stop to further develop your craft. It is always ongoing because there will always be something new in the programming realm to learn and study for the simple fact that technology is always a growing and advancing industry.

“First, accept the fact that you may be considered a bit strange for what you want to become. Second, keep your focus on the long term. During your apprenticeship, value learning and long-term growth opportunities over salary and traditional notions of leadership. People aspiring to become masters of software craftsmanship need to plan for the long term. This long (yet bright) journey will bring you a rich set of abilities. You will become skilled at learning, problem solving, and developing strong relationships with your customers. You will come to wield knowledge and technology as the samurai uses his short and long swords. You will come to comprehend and appreciate the deeper truths of software development. But all this will take time.”

This idea stood out to me the most and it definitely changed the way I think about the journey on mastering my craft as a developer. Back when I was just learning my first programming language, which was C++, I thought that quickly becoming proficient proved that I was a “master” at it. Now I realized that wasn’t the case. After realizing this, the process of mastering a craft has to take time. The process can involve making mistakes, but that’s fine. For me as an individual, I learn best after I make the mistakes so I know what not to do and I know how to approach the problem the right way.

Considering that I do want to become a video game developer, this pattern also taught me that aspirations to be in leadership positions such as a manager or other promotional positions can get in the way of the learning and growth opportunities on becoming a master craftsman. Now when I approach the position of a video game developer, I’ll be sure to love the journey to grow and become the best developer and programmer I can be.

Emptying the Cup: Retreat into Competence

In this Apprenticeship pattern “Retreat Into Competence”, it explains that at times, an apprentice might need to take a step back from their ideas or objectives in order to fully approach the idea or objective effectively. This could mean that you as an apprentice may need to take a step back in order to clear your mind from what you know, and what you think you know to be able to allow new ideas and motives to flow into your mind, which would allow you to develop new crafts as an apprentice. Attaining these newfound ideas can be learned from your teammates and experts.

“Pull back, then launch forward like a stone from a catapult. Retreat briefly into your competence to regain your composure. Take some time to build something that you know how to build. Then use that experience to recognize how far you’ve come and how much you are currently capable of.”

I agree with this statement of retreating briefly into your competence. The way I see this idea is that it is basically telling you to reset yourself or revert yourself back into a new apprentice. This means that you have a fresh mind and you feel open to new ideas because you have the motive to learn new things from others around you.

“This pattern is most relevant for people who have stretched themselves far beyond their ability. If your apprenticeship has you taking reasonable-sized steps forward, taking on gradually increasing responsibilities and technical complexity, then you may not need to take shelter in this pattern. But if you are really struggling or are barely keeping your head above water in The Deep End, look for opportunities to temporarily retreat. Sometimes you need to take one step back in order to take two steps forward. When you do this, it is important to turn that backward movement into forward momentum as quickly as possible. That forward momentum is revealed in your possession of more knowledge and greater skill than you had yesterday.”

This part of the apprenticeship pattern was useful to me because it states that it is not good to pull back to far because you may find yourself to settle for initial failure and surrendering to the fear of failing. I would use the retreat time effectively to relearn what I already know in case if I missed something important such as an important basic fundamental instruction in a specific programming language. This pattern will change the way I work and operate in my profession because now, I know that it is normal to retreat a little if I’m stuck on a software development problem, or any real world problem.