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.

Advertisements

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.

Apprenticeship Patterns – Craft over Art

The pattern Craft over Art in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye discusses the opposite approaches one can take when writing software…

On one end of the spectrum there is practicality. This would be considered the “craft” portion of this apprenticeship pattern [AP]. The best way I can describe this side of the spectrum is with the idiom “don’t reinvent the wheel”. If a solution is already there, don’t go out of your way to rewrite it. Why would you waist your time? If there is no currently solution, then find the quickest and most efficient way possible that solves the problems and meets the customer’s demands [AP]. Don’t go above and beyond.

On the other end of the spectrum is the “art” portion of this pattern [AP]. This means that your solution should be beautiful and elegant [AP]. It should be a master piece [AP]. The tradeoff here is that creating masterpieces takes both time and money. Although the pattern seems to lean towards favoring the “art” side of things, it does suggest that there are times where you’ll have to find a middle groud between the two [AP].

I’ve mentioned this in the past and I’ll mention it again. If you truly want to be a master software developer, then I feel the advice this pattern gives is worth taking. However, in most cases, following this pattern doesn’t seem realistic. Companies have goals and deadlines that need to be meet. They aren’t going to want you to take a week to complete a task that can be done in a day just so you can make it perfect. Time is expensive, so if you can meet the customers demand in a day rather than a week then they are going to expect you to do so.

The pattern also notes how one should be wary about making something beautiful, yet useless [AP]. If you are going to take weeks to perfect something in which a valid solution could be developed in a few days you better be darn sure it is going to work [AP]. This is something that I agree with. Creating something that is useless isn’t craftsmanship or art. It is a waist of time.

Form an overall perspective I get what both this pattern and book are trying to preach. This pattern is great advice if you can find a place that will let you follow these practices. It just doesn’t seem practical. If you are given the opportunity to actually follow these guidelines I say go for it. I just don’t see it as being realistic for most people in most situations.

 

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