In Sprint 4 we finally got our first issue assigned. Unfortunately, our first issue (NGPOC-183) was rather difficult. It took us several days to try and understand how to tackle it and we ended up not being able replicate the problem on the test server. We had posted questions on the issue in JIRA and reached out to the developers on Slack but were not able to get any clarification or guidance. Although this issue has been a dead end so far I did get gain some knowledge in the code base and have better understanding with how the location feature works in the AMPATH dashboard. Right before break our group decided to take on a new issue (APTS-296) but we have not made much progress with it yet. Aside from our issues in JIRA pulling changes from the AMPATH repo as a remote upstream always seems to create a lot of conflicts and problems connecting to the test server. It hasn’t been anything we haven’t been able to work through but does slow progress down. We find it better to pull in changes frequently to make sure we are up to date and our changes will cause as little conflict as possible if we can get to a pull request. Looking back at the last sprint we did what we could for our first issue but the lack of further guidance slowed us down and kept us from any measurable progress. Looking forward we hope to make considerable progress on our new issue and move towards our first pull request. As of right now the team is still working well together and we aren’t going to adjust our velocity for the next sprint.
Chapter 3 covers the topic of what exactly software craftsmanship is. The author generalizes it by stating its putting responsibility, professionalism, pragmatism, and pride into software development. He then goes on a long walk through of how software craftsmanship came to be and the history behind it. Basically software craftsmanship has been around since 1999 however it never really gained traction until about 2009 when the Manifesto was published online. The Software Craftsman Manifesto outlines four main values of a developer: 1) Not only working software, but also well-crafted software. 2) Not only responding to change, but also steadily adding value. 3) Not only individuals and interactions, but also a community of professionals. 4) Not only customer collaboration, but also productive partnerships. The author concludes with the main idea that software craftsmanship is a lifestyle and mindset of professionalism in software development and always striving to provide the best service to clients.
After reading chapter 3 I thought there were some really good points but I did think the history was a little drawn out for the reader. I agree with the manifesto the author laid out however everything he mentioned seemed to be common sense. It is also something that must be embraced by the entire business for it to be effective. While one developer could be a craftsman, it takes everyone to follow the manifesto for it to truly work and give the client the best experience possible. My favorite idea from this chapter was the ‘craftsman swap’ where developers from different companies would trade places and act as if they were a developer at another company for a week. This is a great way for teams to get an idea of what they could do better and sheds some light on how other companies are operating. Both teams benefit and can adopt the best practices from the combination of two teams. I can however see where competing companies may not want to have their competition directly working with their team to gain any kind of competitive edge. Overall, I think the Manifesto for craftsmanship holds good points any developer should be following and sets a higher standard for developers everywhere.
Chapter 4 covers the topic of attitude being a software craftsman. The author makes a point to make it clear that we as individuals are responsible for our own careers and continued learning. While it’s nice to work for employers who invest in their employees we are ultimately responsible for keeping ourselves trained and up to date. He goes on to talk about all the different ways we can keep up on our training so that we are always learning. First he mentions reading material in the form of books, blogs, or technical websites. The author does mention even beginner developers should keep a blog to document and track their progress. Next he talks about ways to practice. When practicing a problem it’s important to focus on how the problem is actually being solved and not just writing code that works. Katas which are short coding exercises or doing personal pet projects are also some suggested ways to get good practice in. Lastly the author touches upon time management. Many times we tell ourselves we are too busy but he insists to make time. We can do this by limiting habits like TV watching or social media use. He does make a point that there needs to be a good work life balance but to own your own career you must manage time wisely and keep your skills sharp outside of normal working hours.
After reading chapter 4 I noticed a lot of commonalities mentioned from Robert Martin’s Clean Coder. I strongly believe it is an individual responsibility to continue software learning at any career stage. Out of the ways mentioned I find myself following social media and blogs the most. With the speed that tools and technologies come out, blogs tend to have good early information and usually tutorials to help you learn. One thing I’m not sure I fully agree with is the Pomodoro Technique. While I think it may be useful for someone who’s off track, setting timers and keeping such a rigid schedule does not seem sustainable. Personally I know I would keep checking the time remaining which would hinder my focus. In conclusion my career will surely benefit from personal learning and proper time management skills.
Chapter 1 covers the topic of software development in the 21st century. Basically the author is introducing the overall theme of the book in that today’s developers are expected to be software craftsman. Just being able to write code isn’t good enough, a developer needs to have the ability to contribute to the business in as many ways as possible. The author also points out what seems to be a flaw that seniority among developers is earned by years of experience instead of knowledge. He argues that developer’s experience can be so different across technologies and industries that just years of experience should not indicate seniority. In conclusion the author is preparing the reader to learn how to become a software craftsman like he mentions.
After reading chapter 1 there’s not too much information yet but I think the author made a couple good points. The first one being that he basically demoted himself from architect to developer for the simple goal of being happier. I think it’s important to remember that in order to be successful you need to be happy above all else. I don’t think maintaining a job you are completely dissatisfied with is sustainable. I also agree with the author’s thoughts on seniority. While years of experience definitely holds value, someone with proficient knowledge of a subject shouldn’t be thought of as junior just because they haven’t developed for as many years.
Chapter 2 covers the topic of Agile development. The author gives a general idea and history of the methodology. Basically Agile was created by the most influential developers in the early 2000’s to address both process and technical oriented disciplines. These disciplines would ensure developers built the right thing and built that thing right by getting the most feedback as possible through quick and short iterative work cycles. Agile completely changed the development world and gave control to small teams who played all the roles of software development following the 12 principles of the Agile Manifesto. While the Agile takeover massively improved communication in business, it ultimately led to the Agile hangover as the author calls it. Companies were using Agile only as a process improvement and maintained their sub-par technical disciplines. Before long, companies who had adopted Agile development were back to their old ways and not seeing the results they expected. The author blames this on the companies only committing to partial transformations and neglecting to improve their technical disciplines. The author concludes saying that software craftsmanship and the Agile methodology can work together for best practice. While Agile will improve upon the development process, software craftsmanship will promote better technical practice and doing more for the client.
After reading chapter 2, my thoughts of Scrum have been reconfirmed. As one of the most popular Agile implementations, Scrum has taught me the importance of constant feedback and changing demands to work in the most efficient way possible. I can definitely see how the Agile hangover was destined to happen. Focusing on the development process was a great idea but lower level disciplines of writing good code should have been enforced before if not alongside the adopting of Agile techniques. This really shows that no method or technique can outweigh bad code or lack of technical discipline. Having seen the effects of only focusing on improving processes I do wonder if Agile coaches and professional training seminars are better equipped to address the importance of technical improvement alongside Agile development for optimum results. In summary Agile development is a great technique for a development team but must be accompanied by correct technical practice through software craftsmanship.
In sprint 3 we got more involved with writing code for AMPATH. Basically, each group member tried to write the authentication module from scratch. I was able to write about 50% on my own but needed to do a lot of verification with the working module. This was about the level of knowledge for the whole group. Our definition of done for this task was to just do as much as we could on our own and use the working module for assistance as needed. We decided on this because we need to be moving forward with more meaningful tasks. Also during this sprint, the AMPATH developers added a new test server for us to connect to for running an AMPATH instance. This was very helpful because we were constantly having issues with the openMRS standalone and its server. The whole group was able to connect to the new test server pretty quickly and it has not given us any trouble since. The last major task for this sprint was creating our account and getting logged in to AMPATH’s JIRA system. This system is used for issue tracking and with an account we can assign ourselves to specific issues. Our group was assigned one issue so far but we weren’t able to nor did we plan to get to it this sprint. Overall our group had a successful third sprint. We were able to get the tasks we committed to done and our knowledge of the AMPATH code base has been getting stronger. The only thing our group needs to improve on is our daily scrums in Slack. We have great communication in class and everyone is doing their tasks but we are struggling to communicate our progress outside of class time. I believe in the next sprint communication will be easier because we will all be working on the same issue. Up until now our tasks have been individual so working together has only been necessary if we get stuck on something. In conclusion another strong sprint for TeamLoading.
Chapter 13 covers the topic of teams and projects. The author talks about two different approaches with projects. The first approach is that a team is selected for a specific project. Usually these people who are selected are also working on several other projects and they are not familiar with each other’s work habits. This type of team usually works slow and is not the most effective in completing a project. The second approach is to select a team that highlights all the necessary skills and keep them together for as many projects as possible. Over time this team will start to “gel” as the author calls it and will become extremely efficient at working together. The only down side that is mentioned is relative to the project owner. The project owner lacks some security in relying on their team’s resources because the team can make a short term allocation of all their effort to another project in an emergency. In conclusion the main lesson here is to form a good team and move through projects together, getting better after each one.
After reading chapter 13 I definitely think the approach of forming a team and keeping them together makes the most sense. By working with the same individuals you can build relationships and form a reliable team that can get projects completed. Unfortunately, as a junior developer I will have little influence on how a company or department approaches their projects. I will however keep this team approach in mind for project decisions when I am more senior. I think it’s important to note that sometimes a team may need to change some of the members intentionally. Maybe one person isn’t working well with others or maybe you need to add a member with a special skill. Keeping a team together is important but I think there should be an overall assessment after each project to make sure improvements are being made when possible.
Chapter 14 covers the topics of mentoring, apprenticeship, and craftsmanship. The author first talks about the different forms mentoring can take. It could be a programming manual, observing a teacher, or really anything that pushes you in the direction of improving your knowledge. He then makes a point that in programming recent graduates often get thrown on to teams without a true training phase like most other professions. He talks about a hypothetical hierarchy of master programmers, journeyman, and apprentices. As a programmer gains experience they shed some of their technical supervision and gain responsibilities including mentoring those junior to them. This chain reaction of elders teaching the young is what leads to programmers becoming true craftsmen and professionals. When junior programmers have good role models they become those role models over time.
After reading chapter 14 it’s clear that proper mentoring is necessary to grow into a craftsmen programmer. I don’t think the author places enough responsibility on the junior programmers though. As a young programmer it’s important to recognize the proper role model and seek mentorship from the more senior programmers who are doing things right. While mentors should reach out to the junior programmers it’s still important to take charge of your own path. Entering the software development field, I’d like to think I will have good mentors that will help guide me in the right direction as I move through my career. If I find that I lack the proper mentors, I will do my best to seek out the professionals I will need to one day become a mentor for those junior to me.