Chapter 1 covers the topic of software development in the 21^st 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.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

Finally we completed our 3rd sprint. The good news is I was finally able to fix the “Unable to start OpenMRS”. It was to do with the path with spaces problem. Just removing spaces from the folders where the standalone was extracted fixed the issue. On the other hand, the not so good news, is we don’t need OpenMRS standalone anymore since we got AMPATH test2 server to work on.

Moreover, this week we got chance to to take part in online conference with developers of AMPATH. It was exciting to listen about the improvements and changelogs they did with the project.

The main task for the sprint was to get connected to  AMPATH JIRA system and fix NGPOC-183 issue. The bug behind the issue was “After login it allows free text when selecting location and saves successfully.” But when we tried to reproduce the issue, any free text such as ‘blablabalba’ did not saved that it a location. One of our team mate has posted for more classification. We haven’t received a reply yet. In the mean time, I am going through the AMPATH code, particularity the modules that has to do with our issue.

From the blog CS@Worcester – Software Dev Capstone by osworup007 and used with permission of the author. All other rights reserved by the author.

Chapter 13 “Team and Projects” discusses about team management and its formation. Martin suggests it is better to form persistent teams that move together from one project to the next and can take on more than one project at a time. He conveys the concept of a gelled team. The team members begin to frame connections. They figure out how to work together with each other. They take in each other’s characteristics, qualities, and shortcomings. In the long run the group starts to gel. Ultimately, a gelled team plan together, solve problems together, face issues together, and get things done.

I sense more confident in my work while I am working with the same person over and over again. We get to know each other opinions, skills, and abilities. It’s better to know the person with whom we are working at a personal level. It helps to form friendships.  When managed properly, I feel teamwork always is a better way to work.

The next and the final chapter of the book “Mentoring, Apprenticeship, and Craftsmanship” revolves around some of the key information that we might face in the real world after being a CS graduate. I feel this was the perfect chapter to end the book. Martin believes in adapting a program of apprenticeship rather than just learning the theory of computer programming in schools. Furthermore, author also introduced a system of masters, journeymen, and apprentices. He summarizes after apprentices knows know design principles, design patterns, disciplines, and rituals; if the masters agree, then the apprentice becomes a journeyman.

I do feel it’s all about years and years of hard work and experiences. Once we stepped into CS field we should always be learning and be willing to grow our skills.

Ultimately this post brings to the end of the series. Looking forward to read another exciting book.

From the blog CS@Worcester – Software Dev Capstone by osworup007 and used with permission of the author. All other rights reserved by the author.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.