Chapter seven, entitled “Technical Practices,” covers the topics of ideal programming practices and why they should be utilized in the field.  Of course by best practices I’m speaking of TDD, CI, paired programming, etc.  These are the topics that have been covered at length in The Clean Coder and my related blogs.  I found it interesting that Mancuso has a separate section for refactoring outside of TDD.  For those who are unaware, refactoring is a step within test driven development.  Therefore, if TDD has been utilized, then there is no need to explicitly describe refactoring.

Chapter eight, entitled “The Long Road,” is an interesting chapter about career choices. We all know that money is a motivating factor when making career choices, but taking money out of the equation leaves you with the following three factors:

Autonomy: It is when we are in control of what we do, how we do it, and when we do it. That should always be the case in a true Agile context.

Mastery: It is when we are constantly learning and evolving—becoming bet- ter professionals and better human beings.

Purpose: It is when we feel that our job is important and we are contributing to make things better—instead of just doing what we are told without under- standing why.

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

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.

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.

For this post I read chapters 3 and 4 out of Sandro Mancuso’s The Software Craftsman.  In these chapters Mancuso breaks down what he means by Software Craftsmanship.  First and foremost a Software Craftsman is a professional who is constantly learning new tools and techniques.  In chapter 3, “Software Craftsmanship,” Mancuso presents and explains the Software Craftsmanship Manifesto:

Not only working software,
but also well-crafted software

Not only responding to change,
but also steadily adding value

Not only individuals and interactions,
but also a community of professionals

Not only customer collaboration,
but also productive partnerships

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

Fitting that the last chapter in Robert C. Martin’s The Clean Coder was about craftsmanship, now we are reading The Software Craftsman: Professionalism, Pragmatism, Pride by Sandro Mancuso.  I’ve read the first couple of chapters of Mancuso’s book and I’m not sure if I like this book any more or any less than the previous one.  I suppose that is fortunate.

The first chapter was titled “Software Development in the Twenty-First Century” and this chapter is about as long as the title.  Chapter one was all of six pages long and served only as an introduction to the rest of the book.  Mancuso did discuss the idea of seniority in the field of software development and broached the topic of Agile, the topic of the next chapter.  There wasn’t really enough content to reflect on this particular chapter.

Agile!  I love it, I LOVE it.  I’ve read and heard so much about the Agile process in the past year, and aside from the fact that its the direction businesses are moving, it just makes sense.  I’m pretty sure I have blogged about Agile before, but if not, I’m happy to do it again.  Most importantly we need to include the Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others to do it. Through this work we have come to value:

• Individuals and interactions over process and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

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

This week I read the final two chapters of Robert C. Martin’s The Clean Coder.  These chapters were not very long and only covered a couple topics.  In fact I only took away two points from chapter 13 on “Teams and Projects.”  These two topics were on the “Gelled Team” and “Velocity.”  A quick overview on Martin’s “Gelled Team” is a group of about twelve programmers, testers, analysts, and one project manager, who have worked long enough together to develop a symbiotic relationship.  I have worked closely with a few students during my time at WSU and we have certainly developed something close to what Martin described.  I know how these students think and work, and it aligns well with my process.  Martin describes “velocity” which my group and I have been experimenting with and adjusting as we figure out how much work we can accomplish over our sprints.

Chapter 14 was entitled “Apprenticeship, and Craftsmanship” which focused on the idea that school does not prepare programmers for the field.  To be honest I am concerned that I have not accrued enough knowledge to be an effective programmer in the field.  Martin suggests a system in which there are Masters, Journeymen, and Apprentices, where the more experienced teach the less experienced.  I like this idea, where for the first year, the Journeymen teach the Apprentices, and over time the Journeymen become Masters who orchestrate the entire process.  Martin also discusses the idea of Craftsmanship, which he calls “a mindset of values, disciplines, techniques, attitudes, and answers,” which are handed down from the experienced to the inexperienced.

Well that wraps up, The Clean Coder.  Stay tuned for more posts starting next week on a whole new text!

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

Another week, another two chapters from Robert C. Martin’s The Clean Coder.  This weeks installment were chapter’s 11 and 12 which were entitled “Pressure” and “Collaboration” respectively.  They combined for eighteen pages of fluff.  Each contained the signature Bobby Marty anecdote which ate up a large portion of both chapters.  In my last post about The Clean Coder I said that I was starting to enjoy his chapters.  I guess I spoke too soon.

So chapter 11 was about pressure.  Martin writes about avoiding pressure and handling pressure.  I found it interesting that Martin thinks maintaining discipline is both a way to avoid pressure and to handle pressure.  He uses TDD as an example.  The problem with TDD is that it is time consuming.  Not only do you have to think of the code you need to write, but you need to write tests that the code will eventually need to pass.  This means that you will be writing twice as much.  His idealistic position on deadlines is unrealistic.  Sometimes you need to make adjustments in order to make deadlines, and in those cases, disciplines must adapt.  TDD may be the best way to do something, but sometimes sacrifices must be made.

Chapter 12 was about collaboration.  It is asinine to resist collaboration for the greatest accomplishments have not been achieved by a single person, but a group of people.  The overall message of this chapter is that working with other people is important, and I don’t think that many people would disagree with that.  I found his section on cerebellums to be superfluous and poorly labeled.  Cerebellum has very little to do out of the context of that billboard he read, and thusly carries little weight outside of that chapter.  I also found that his take on collective ownership interesting.  I feel as though it needs a qualifier.  Collective ownership is certainly the best way to go, IF and only IF you can trust the people you are working with AND you are using a version control system.

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