I was speaking with one of my professors today about Sandro Mancuso’s The Software Craftsman and was expressing my preference of this book to Robert C. Martin’s The Clean Coder.  I may have deluded myself into believing that Mancuso uses less anecdotes than Martin in his writings.  I am not infallible.  Mancuso does use an exorbitant amount of anecdotes in his book.

Chapter five is called “Heroes, Goodwill, and Professionalism” and after reading the chapter I’m still not sure I understand what the title means.  Goodwill does not even appear in the chapter.  This chapter reminds me of parts of a few chapters from The Clean Coder especially the chapter on “How to Say ‘No.’”  I’m not going to recap previous blogs so if you are interested in Professionalism I invite you to read my series of blogs on The Clean Coder as that is the theme of that book.

Chapter six is called “Working Software” and it is a pretty simple chapter.  Essentially the main idea behind this chapter is that if code is going to be used for any extended period of time, it must be written properly.  “Working software is not enough.”  Rushing through the process and skipping steps is going to cost you time later, so it is in your best interest to take your time.  Mancuso also describes how to address legacy code.  He points out that nobody likes working with legacy code, but a change in attitude can make a world of difference.  Isn’t that true of everything though?

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

Chapter 15 was all about the benefits of writing quality/expensive code vs. average/cheap code. It is a myth that quality code is expensive. According to the book, often managers must choose between producing quality products which take time to produce and average code that does not take much time to produce.  It is the duty of software craftsmen to produce clean quality code that is inexpensive.

Overall, what I learnt from this chapter is that quality code is not expensive. The lack of skills on the part of the developer is what makes quality code expensive. Developers must do their best to produce quality code which is inexpensive.

Chapter 16 was about what it means to be a software craftsman and how to have a successful carrier. The #1 word that summarizes what it means to be a software craftsman is passion. Software craftsmen are passionate developers and they love what they do. Being a software craftsman means that you much constantly learn and improve your craft/skills. You are in a journey to mastery. Mastery of software development is a long hard road. Every carrier decision you make must be in order to move you forward in your goal to mastery. And also, as mentioned in the previous chapters a job is a mutually beneficial relationship. Both the employer and the employee must get the best out of the relationship.

To sum up, I learnt about what is takes to develop quality/inexpensive software and what it means to be a software craftsman from reading these chapters.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

Sprint 6 marks the final sprint of our semester.  Our goal was to complete APTS-254 issue by the end the sprint.  The rest of our group ran into roadblocks and joined us in our endeavor.  We also hit roadblocks and needed more clarification.  Even though we found where in the code we needed to add the case, we weren’t positive about what the established reminders were doing.  So we determined that the only way we would be able to figure out exactly how these reminders worked was to recreate the scenarios in which they would appear.  Unfortunately, we were unable ETL server to work on our computers so we were essentially taking shots in the dark.

With all of this uncertainty, and the delayed response time from the people at Ampath, it was virtually impossible to accomplish anything of any substance.  In the end we were unable to complete our goal of finishing APTS-254, which means that we were only able to complete one issue this semester.  Perhaps I set lofty goals for our team, or maybe we underperformed, but one thing is for sure.  I can’t wait to spend way more time developing my own Angular 2 project.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

Sprint 5 began with our solution to NGPOC-185 was pulled into Ampath.  We also started work on some new issues we assigned ourselves from JIRA.  In accordance with what we decided last week we picked two issues, one for each group of three.  Our group picked APTS-254 which was described as “User are requesting when a patient switches to 2nd Line the Viral Load Pop-up reminder should not pop until the patient has used the 2nd Line Regimen for 6 months.”  Just as we did with NGPOC-185, we decided the best course of action was to attempt to recreate the issue and then find where in the code the issue was located.  Neither individually nor as a group could the issue be recreated so we determined that we needed additional clarification on the issue.  I wrote a message to Ampath, but it took awhile to get a response, delaying our progress.  Before the sprint ended, we did get a response.  Apparently the issue was located in the ETL Rest Server, which we did not have before.  They directed us to the repository, but even with this new information we were unable to recreate the issue.  We will continue to work on this issue next sprint.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

To start our fourth sprint we divided the NGPOC-185 issue into distinct parts so that everyone on our team could dig their hands into the issue.  We broke the task into six parts and everyone picked a piece they thought they would do best.  I was going to take everyone’s individual piece and combine them into the final solution.  Unfortunately, we were mistaken.  Our solution was incorrect because our approach was all wrong.  Over Spring Break one of the members of our group determined that the solution was much more simple than what we were attempting.  Once I returned from Spring Break, I had a chance to review his approach.  Apparently we were looking at the wrong thing and once we received some clarification the solution came together in a couple of days.

With our solution complete, we determined that these issues were not as complicated as we originally thought, and broke our group into groups of three.  This way we can complete twice as many issues per sprint.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

This past sprint our class was assigned four issues on JIRA, an issue-tracking software. AMPATH set all of us up with our own login information so that we could view, assign, and comment on the issues.  The issue we wanted to work on was given to another group, so we ended up getting our second choice, called NGPOC-185.  The title of NGPOC-185 was “Logout not working when editing a form” and had the description “if you are in the middle of editing a form, but you decide to cancel and logout (may not be a practical case) , after accepting to cancel, it should log you out.”

As a team we determined that the issue was asking us to have a confirmation window pop up when a user tries to logout while they are editing a form.  So we figured our first step would be try to recreate the issue.  We booted up our local server and determined what the issue was describing.  Our next step was to find the code the corresponded to the issue.  After some searching we think we figured out where to begin.  We decided our best course of action was to read up on Materialize CSS and then attempt the issue next sprint.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

Chapter 13 is all about creating a culture of learning at your company. Here are some of the things that the author thinks can be done to improve the morale and create a culture of learning:

1. Start a book club.
2. Have a tech lunch.
3. Have group discussions.
4. Conduct group code reviews.
5. Have hands-on coding sessions.
6. Start internal communities of practice.
7. Encourage pet-project time.
8. Engage with external technical communities.

Creating a culture of learning and motivating developers is important for a company as it directly impacts the code developers write. Ultimately, this depends on the developers; hiring passionate developers and providing them with a good environment would improve the innovation of the company.

Chapter 14 is about how to convince skeptics into adopting new practices or changing the culture. The first step according to the book is to identify the type of skeptics. The following are the types of skeptics the book talks about:

1. The uninformed.
2. The herd.
3. The cynic.
4. The burned.
5. The time crunched.
6. The boss.
7. The irrational.
8. The indifferent.
9. The wronged.
10. The inept.
11. The ivory-tower architect.
12. The insecure.
13. The fanboy.

The chapter goes on and on about how to convince these skeptics to adopt something. Overall, what I got out of this chapter is that I must be good at what I do, I must communicate clearly, and I must establish trust to drive change.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.