Sprint 6 Retrospective

Well here we are – the end of the last full sprint for the spring 2018 semester. Honestly, it is a bit surreal. Everyone in this class has been working towards the goal of an undergraduate degree for the vast majority of their lives and now we are all just weeks away from achieving this goal. It is awesome to see everyone in the class continuing to work hard on this project with Ampath. It would be very easy for us to check out at this point in the semester.

I understand that this retrospective blog is supposed to focus on the current sprint, but seeing how this is the last opportunity I am going to have to write this blog for this class, I’d like to take a moment to reflect on what “The Perfect Name” was able to accomplish this semester. So, please bear with me…

I couldn’t be prouder of what our team was able to accomplish this semester. Our knowledge about the Ampath project, Angular, Typescript, Agile software development, etc. has grown tremendously. We have all come a long way when compared to the beginning of the semester. The learning curve for this project was quite steep and even with that we were still able to produce a demonstrable feature by the end of the semester. Although we may not have accomplished everything we set out to do at the start, we still made great strides towards the ultimate goal and have put whoever takes over the feature in a good spot to complete it. Now, onto a retrospective more focused on this sprint…

As usual, the team work very well together this sprint. No one is afraid to ask question at this point and everyone tries to help out anywhere and everywhere they can. If I’m being honest I would say last sprint was probably a bit more productive than this sprint, but I’d say this was our second most productive sprint of the semester. This sprint we had to take a step back and look at where we stood compared with the goal we had set at the beginning of the semester. During planning we all agreed we weren’t going to totally reach our goal; we did not implement the encryption service and we weren’t able to add the ability to store multiple users. We agreed everything else we had set out to do at the start of the semester would be done by the end of the semester. Because we agreed we weren’t going accomplish everything, we set out this sprint to leave whoever takes over for us in the best position possible. To do this we had two main goals: completely finish any outstanding tasks – we felt it was better to make sure we finished the work we had already started the right way rather than rushing through it to try and make an attempt at the encryption service and/or multiple user storage (it wasn’t realistic to finish either given the time constants), and to thoroughly document what we were able to accomplish so whoever takes over wouldn’t have to waste their time figuring out what was done.

I am happy to report that we were able to accomplish most of the goals I mentioned above this sprint. We created a document explaining what was done, where the code was changed, etc. This document can be found on our team page of the CS448 Slack channel. Hopefully it will be useful to whoever takes over. We are still working on the backend for the offline credential storage checkbox, but we are confident it will be done by the end of the semester. Once the backend is done, all that we will be leaving outstanding is encrypting the password (which will hopefully be simple with the help of the encryption team’s work) and storing multiple users. It was really nice to see ideas actually play out, even if it wasn’t as quite as feature rich as we had originally hopped for. The documentation and backend were the two main goals this sprint, but obviously there were several other smaller things accomplished as well (some research, tests, minor bug fixes, etc).

Lastly, I’d like to thank everyone involved with this project for a great semester. I couldn’t have asked for a better group of people to work with. I know I made some new friends along the way. I hope that was the case for others as well!


Sprint 5 Retrospective

As we enter the home stretch, the team has continued to make good progress on the project. It’s weird to think we only have four weeks or so left in the semester. It has flown by! The team continues to work well together and communication is never an issue. In fact, I’d say it is even one of our strengths. Even on days we don’t have class and we are at work and/or busy doing other things, team members are quick to respond to each other’s questions, put pull requests through, etc. Good communication is always vitally important to the success of a project, so it is great to see us excelling at this. I don’t have any pressing complaints or need-to-work-ons at this point. I think a lot of that stuff was hashed out earlier in the semester and if an issue comes up now, we are quick to address it mid-sprint rather than putting it off.

For sprint five, the team set out to further improve the rudimentary version of the offline login service that we created last sprint. We were able to make some progress towards this, although it still isn’t quite all the way there (it wasn’t expected to be all the way there this sprint). The other main goal of this sprint was to get Ampath’s approval for our plan to implement the offline login service. To do this, we reviewed and updated the high level designs I had created earlier as a team. I thought this was a very good exercise as it allowed for us to make sure that everyone is on the same page. We were able to present these designs to Ampath to ensure that we were going about this the correct way. They approved of the design without asking for any changes to be made to it, so we can press on with the implementation of the design with full confidence now. It was nice that we were able to get this approved because now we don’t have that lingering concern in the back of heads that we might have to scrap everything we had done.

Although those were the two main goals this sprint, we also got a bunch of other stuff done. We were able to make progress towards updating the GUI to give the user the option of storing the credentials offline rather than just doing it automatically. This is an important feature to have because we don’t want to be storing credentials for every single user that logins into the app. This is not only inefficient but, could also cause security problems. All of us were also able to do some research on subscription processing. This was done because another team is planning to use this.  George was able to fix the OnlineTrackerComponent bug and make a pull request to Ampath to fix this issue. Kudos to him for taking this on. It was a bug found mid sprint, so it could have waited until next sprint as we had already committed to a bunch of work, but he took it on anyhow. We were also able to document out new Git approach after there was a bit of hiccup this sprint (luckily, we were able to get it fixed). Several other minor tasks in addition to what I’ve mentioned were completed as well.

Next sprint is our last full sprint for the semester. I believe the plan is to continue to work on implementing the offline login service, however I think documentation of what we have done and what still needs to be done should also be a focus. This way both the Ampath folks and, should a team in next year’s capstone pick off where we left off, will be able to tell what progress/changes were made. It should make their lives’ significantly easier and prevent them from having to start from scratch.

Apprenticeship Patterns – The Deep End

The Deep End pattern in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye discusses an important hurdle any good software developer will find themselves in at least once in their career. Complacency is a dangerous thing and can often cause a person to get stuck in a rut[AP]. People who want to move up in the world have to be willing to take risks and bigger leaps than they would normally feel comfortable doing[AP]. That is what this pattern is all about; taking the risky jump.

If you are comfortable where you are and don’t see a need to move up or change what you do, then making small incremental changes is perfectly fine. However, most people at some point are going to want to really switch things up. The issue is they are often scared because they are not confident that they will be able to succeed with the big change[AP]. If you really want the change you are going to have to be willing to take that risk[AP]. This “big change” could be something like accepting that great promotion you were afraid to take in the past, taking an assignment in a foreign country, or even switching companies[AP].

By taking on roles you are uncomfortable with, you will grow your portfolio, experience, social group, etc. Most of the time the benefits outweigh the drawbacks. However, the pattern notes that you have to be aware of when you are truly getting in over your head[AP]. You have to know when to ask for help or when take a step back and reevaluate[AP]. Don’t feel like you have to do it all on your own simply because you knew the risk you were taking. If you fail, or decide that the change you made is not right for you, it will not ruin you or your career if you take the right approach[AP].

I generally agree with what this pattern has to say. There is certainly risk involved in making a big move, especially if you are comfortable with where you are in your career, but I think it is a risk most developers have to take at some point in order to become a master craftsman. You can’t wait until you are ready to change things up. You’ll never actually end up doing it. There has to be a bit of blind faith. Even if it doesn’t work out, there is such a demand for people in this field you will almost certainly have a soft landing.


Link to pattern in book: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch02s07.html

Sprint 4 Retrospective

This sprint The Perfect Name pressed onward with the implementation of the offline logon service. We are continue make progress towards our goal, although it has been a bit of a grind in my opinion. The group continues to work well as a unit. We always seem to have a good idea of what each of us is working on and there is good communication both inside and outside of the classroom. One thing I think we could do better is to have better communication with the other teams. I feel that we often get so busy working on own stuff we forget to check and makes sure we are all on the same page.

This sprint the main goal was to actually start working on implementing the offline logon service. George took on the brunt of that work along with other team members pitching in along the way. Although it is still a work in progress, you can see that significant strides were made on this. There is now a rough working version of it. Although the main goal of the sprint was to work on the offline logon service, there was a bunch of other tasks that needed to be done that were necessary for us and/or the offline logon service depends on. We were able to put together a high level design (HLD) for the front end of the offline logon service. The goal behind this was to determine how we are going to allow the user to choose whether they want to store their credentials temporarily offline. We felt that it is was best to give the user the option because space is likely a limiting factor. It may not be possible to store every single user’s credentials and even if it is it wouldn’t be very efficient. The HLD for the this can be found on Balsamiq as well as the AMPATH documentation thread of the CS-448 Slack page.

Also on the to do list for this sprint was to familiarize ourselves with PouchDb. The reasoning for this at the start of the sprint was although we really only need to store one item in the database, we still felt it was important to have a good understanding of how the database works because it likely what will be used for the offline data storage. Everyone got a chance to look into this. I know few others and myself had gone through some tutorials on it as well. I was also able to install PouchDb on my local copy of ng2-amrs. Jason’s fix came in handy here. In addition to his steps, I also needed to disable my antivirus. It was causing problems when the install was trying to rename some files. I notified the teams on Slack about this incase they ran into the same problem. During the sprint review today we decided that we might head in a different direction regarding how we will store the credentials, but it was still a good learning experience nonetheless. We also began to work on defining the API for the offline logon service and we discussed HLD for the backend of the offline logon service. This will really come together more as we get a better idea of where we are heading.

A lot was accomplished this sprint. I think it was our most productive sprint to date. We are getting there. It is a slow process, but we are getting closer each and every week.

Apprenticeship Patterns – Sweep the Floor

The Sweep the Floor pattern in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye discusses some of the obstacles a person may face when joining a new team. Joining a new team is challenge for everyone, no matter their skill level or amount of experience [AP]. The team your are joining has to feel you out and you have to feel out the new team to get an idea of where you place is within it [AP]. This can be a daunting task, especially if you have never done it before.

The pattern suggests to try and take on simpler tasks to start such as code review or product support [AP]. The team is more apt to let you take on these tasks not only because their time could probably be better spent elsewhere, but also because the simple tasks inherently have less risk involved [AP]. Chances are it isn’t the end of the world if it isn’t completed in time and if it does have to be completed by a certain time they know that it is easy enough for them to pick up and finish. The other suggestion the pattern has is to take on the “dirty work” [AP]. This could be something like updating documentation (what developer wants to spend time of documentation?) or maintaining a development environment [AP]. Chances are you’ll earn some brownie points for taking on tasks like this as well.

I can personally attest to this. When I first started my internship I did a lot of documentation work. It was one of the few things at the time I felt comfortable doing because I knew it wasn’t the end of the world if it was done incorrectly or not completed on time. This helped me a lot because by writing documentation I got to know the project I was working on well. Gradually I was given more complex and critical tasks. Almost two years later I am comfortable with grabbing just about any task off the board.

One thing you have to be careful of is becoming the teams “gopher” as the book puts in it [AP]. In other words, you don’t want to get stuck doing these tasks all of the time simply because the team knows you can do them and/or assumes you like to do them. You have to be willing to push your boundaries a bit to assure this doesn’t happen [AP].


Link to pattern in book: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch04s05.html


Apprenticeship Patterns – Sustainable Motivations

I think most people would say a career in software development is a pretty damn good choice to make. The field is growing at a rapid pace and jobs within the field typically come with high paying salaries and flexible hours. Because of this, it can be easy to find yourself complacent in your current position and lacking the motivation to continue to learn new topics. You may find yourself thinking “I’m making a six-figure salary and I am very comfortable with my current position. Why would I go out of my way to learn new material?” The pattern Sustainable Motivations in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye discusses some ideas on how to prevent/get yourself out of this trap. It also discusses how to avoid some other situations that could potentially prevent you from mastering the craft.

The key to becoming a master software developer is to keep yourself motivated [AP]. As I mentioned earlier, sometimes this motivation can dwindle [AP]. The pattern suggests to keep a list of things that you are motivated by to help remind yourself of what is truly important to you [AP]. I think that this is a great idea. It allows you to keep reality in check. Everyone needs that once in a while. If being considered an expert in your field is on that list, then you should do all in your power to prevent yourself from becoming complacent. If it isn’t and you truly feel that your motivations have changed being an expert is no longer a priority than that is ok. Just don’t give yourself that false intention of wanting to be an expert when in the back of your mind you know your motives are in a different place.

The other thing to keep in mind if you find yourself questioning your motivations and/or if you still want to be in the software field is to simply give it some time [AP]. There are going to be bad weeks at work. There are going to be weeks where you are working nights and weekends to meet a deadline that you knew from the beginning wasn’t realistic. There are going to be weeks where you question management’s decisions. I can go on, but you get the point. Not every week at work is going to be all hunky dory. Be mindful not to make a life changing knee-jerk decision that you may regret. Give it some time and your motivation will probably return.


Link to pattern in book: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch03s03.html


Sprint 3 Retrospective

Now that we are at the end of Sprint three and about to start Sprint 4 we are really starting to get into the thick of things. I am looking forward to really starting to dig in and try to implement what we have been working on the past sprint.

Sprint three went smoothly for the most part. Everyone has been really good about the standups and I think people are getting a feel for how much information they need to provide. The statuses are brief and informative. I feel we are also starting to get more done in the class time we have together. We are continuing down the right path. Having the snow days on Thursday and Tuesday set us back a little as I feel it is critical to have that face to face communication. The standups do a good job at keeping each other up to date on what each team member is working on; it is just no substitution for face to face communication and collaboration. However, that is not to say we weren’t able to accomplish what we wanted to get done this sprint…

The biggest goal of this sprint was to understand how APATH currently implements the logon process. This was my primary focus this sprint because we believe we should be able to leverage a lot of what they already have in their code to help implement the logon process. At this point I feel I have a better understanding of how their logon process works, but I don’t feel I have a full understanding of it yet. There code is relatively organized, but it is quite overwhelming. The biggest challenge is understanding how each service and module interacts with one another. Unfortunately, the code is lacking comments, further adding to the challenge of trying to understand what is happening. It would be nice if they had some sort of high level design architecture type diagram/documentation. I think it would go a long way in painting a picture of how everything intertwines.

Although I still don’t have a very clear understanding of how all of the code works, I feel myself and the team has a good enough understanding to make an attempt at implementing the offline login process. We were able to put together a high level diagram using Balsamiq on how we want to go about implementing this design. I think the diagram helped in painting a better picture of what we want to do.  We also collaborated with the ‘Field Idiots’ to get and understanding on how they are going to implement the offline database. We are going to need to leverage their work to store the  user credentials, so it is important that we stay on the same page. I am a bit concerned that we may have a dependency on their database being up and running. I am not sure if there is any way to “mock” that. We also briefly talked with ‘Everyone Else’ a regarding the encryption process. All of these teams need to mesh together so we can ensure all of our work will work with one another’s.

Lastly, we also took some time to look into the bridge pattern, as it seems we are heading down the road of that type of design. There is a ton of documentation of this online so it was pretty easy to find the information we needed.






Apprenticeship Patterns – Learn How You Fail

People are going to have failures in their field of expertise at one point or another. There is simple no avoiding it. If someone claims that they have never made a mistake I am willing to bet that they are lying or have never even remotely pushed themselves in any way, shape, or form. The pattern Learn How You Fail in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye discusses failure and how to handle failure.

The key message this pattern is trying to convey is how to learn from your failures [AP]. People are always going to be weak in certain areas [AP]. The key is to identify where your weaknesses are and be able to recognize when you are heading into one of those areas [AP]. If you can do that, then you are heading in the correct direction. However, simply identifying where your weaknesses is only one step [AP]. Not taking it any further than that is like a dentist saying you have a cavity and then not repairing it. Once you have found an area of weakness you need to be aware of what is causing that weakness and trying to improve that skillset [AP].

Knowing your weaknesses also allows you to set realistic boundaries [AP]. It allows you to keep your goals in sight without getting too side tracked on other matters that you are probably wasting your time on [AP]. That is not to say you should totally avoid your weaknesses. You are going to have to tackle some of them to get where you want to go.

I generally agree with this philosophy. I have always viewed failures as things that happen naturally and in most cases are a good thing (unless there is a deadline). If you never make any mistakes how are you supposed to learn? Be able to recognize quickly when you have made a mistake so you can take advantage of it. Failure is a bad thing if you never take anything from them. You’ll just end up making the same mistake over and over again. The pattern also suggests keeping a list of your skills and limitations to help yourself recognize when you are heading down the right path and more importantly, when you are heading down the wrong path [AP]. I think keep a list like this is a great idea. It allows for people to more easily recognize what they are good at. I may think about doing this myself. This pattern provides some great advice that I certainly will try to follow and I hope others will as well.


Link to pattern in book: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch05s09.html


Apprenticeship Patterns – Find Mentors

The pattern Find Mentors in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye discussed one of the key tools any apprentice needs to succeed: a mentor. How is one supposed to become a master at their craft if they have no one to model themselves after and no one to turn to for advice? With no mentor there would be no way to go from an apprentice to a master.

In my opinion, finding a mentor is perhaps one of the most important if not the most important thing an apprentice needs in order to succeed. I speak from personal experience when I say this. When I first started my internship some two years ago one of the senior engineers took me under his wing. Now, I was lucky enough that he took the initiative to show to show me the ropes. The amount of knowledge I have gained from working with him is priceless. I am happy to say we still work closely together to this day. It helps that we have a lot of the same likes and interests too. It makes it easier to have a causal conversation and pick his brain a bit because we have so much on common.

Now that I’ve told you my little story, I wanted to mention that the pattern brings up several valid points. First, it is hard to find masters in the field of software development because the field is so new [AP]. Often times you’ll find yourself taking on multiple people experienced in different areas as your mentors [AP]. I certainly have done this. Another thing to note is it may be challenging to get someone to take you under their wing [AP]. Most people with the level of expertise you are looking for are very busy. They may not want to and/or have the time to show you everything [AP]. That being said, the pattern discussed how you must be a bit bold when trying to find a mentor [AP]. This is something I agree with.  The last important point the pattern brings up is that you should return the favor [AP]. If you get to the point where you feel you know enough to pass knowledge on to someone else, even if you aren’t a master, you should take the time to do so [AP]. Remember how appreciative you were when someone shared some insight with you. The person asking for your help will probably be just as appreciative.


Link to pattern: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch04s02.html


Sprint 2 Retrospective

Overall, I felt that Sprint 2 went pretty well. It was the first time going through a full planning session rather than having it set up for us. I felt the planning session went pretty smoothly considering it was the first time all of us were going through it as a team. The team also continues to work well together. I can feel we are getting to know each other better day by day, including both some common personal interests to keep conversations going as well as getting a better idea for what each team member is good at/capable of. I feel that knowing these kinds of things is important for the team to work well as a whole unit rather than a bunch of individual pieces. People are getting better about attending the standups as well, which is good to see as they are important in helping keep each other informed on what is going on in between classes. This also helps prevent duplicating work. We all seem to be on the same page more and more.

We accomplished pretty much everything we wanted to accomplish this sprint. Everyone had a chance to check out Balsamiq. To me it seems like a useful, easy to use, intuitive tool. Hopefully we will get a chance to actually put it to good use at some point later on down the line. We also continued to research angular testing. There is a lot of information out there on it, so I feel this will be a continual activity throughout the semester whenever we have some spare time. Overall, the tests don’t seem overly challenging to write. There was also a continued effort to get eveyone’s ng2-amrs running and connecting to their servers. I believe everyone is up and running on that front.

The big task this week was coming up with design ideas based off of AMPATH’s Google Doc. The document was a bit overwhelming at first as it was a bit of an information overload. There are a lot of good goals/ideas in there, so we decided that it would be best if we focused on one of the goals they had. Otherwise we felt we would be spreading ourselves too thin. The goal of choice was to add the capability to login offline and store data offline. We chose this one because it seems to use that it would be the most useful feature considering the environment/places they work in at times. We ended up making a document with some basic things that we know need to be done in order to accomplish this goal. Some of these included finding a way to encrypt patient data and user passwords. We will have to coordinate with other teams on this as we are aware that another team has already started to look at this. We also know we will need a way to communicate with the main platform and have a way to automatically update their database once the tablet is back online. Those were just a few of them. The whole document can be found on our team’s slack page if you are interested in seeing all of them.

I feel if we continue to work together like we did this sprint we will be in a good place come the end of the semester. I don’t see any major changes that need to be made to the team at this point in time. I look forward to continue to work with my teammates come sprint 3.