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.

So our second sprint has concluded, and with that, the change from posting once every week to posting once every sprint has begun!  Additionally, we have changed our sprints so that instead of having four days of downtime in between sprints, we only have a day.  I really like the way this class is developing.

This sprint included some pretty good steps in the right direction.  Everyone in my group was able to get OpenMRS and AMPATH to  run locally on their machines, and we were able to dig our hands into some code.  Each of us took it upon ourselves to rewrite the AMPATH Authentication Module in order to learn more about REST API.  A few of us, myself included, have already had some experience with this so it has not been a huge leap.  Not everyone, myself included, has completed rewriting the Authentication Module, but I intend to finish it during the next sprint.

Our group really got a good feel for how the sprint cycle works this time around.  We conducted our own sprint planning meeting, broke down our stories into tasks in our own story time, and had a successful sprint review and retrospective.  Everyone has been participating in the daily scrums, and I’m glad to see that our dedication to the process has been fruitful.  I can only imagine that, as a group, we will become more efficient and more productive as the semester continues.

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 another couple chapters out of Robert C. Martin’s The Clean Coder.  These two chapters were entitled “Time Management” and “Estimation.”  Time management is an interesting and important topic in this writer’s opinion.  Martin discusses the importance of meetings, and comments on various methods for limiting these meetings from being time wasters.  He also mentioned a few types of meetings, such as stand-up, iteration, iteration retrospective, and demo meetings.  These are components of the agile process which we have been utilizing in our course thus far.  In my experience with these meetings, I agree with Martin.  If there is not a clear agenda, and if all the members do not maintain focus, a lot of time can be wasted.  Fortunately, we have had pretty good success keeping our meetings on track.  Another topic that Martin broached that I found to be interesting was the Pomodoro Technique.  It is a method for ensuring that time is used effectively and I aim to try using it next time I sit down to do some coding.

As I mentioned, in chapter ten, Martin discusses how to estimate how much time is required for completing tasks.  In his previous chapters he mentioned the importance on estimations, but in this chapter he discusses the process in much more detail, and to my pleasant surprise, provided concrete calculations for how to accomplish adequate estimations.  I hope to employ these techniques in the near future so I can evaluate the validity of his lesson.  As I have read through this book I found that I have been hesitant to believe what Martin has been saying because of the lack of specifics and the overall theoretical nature of the topics.  However, these past few chapters have really started to pull the previous lessons together in a way that makes the whole seem more legitimate.  With only four more chapters to go, I hope that the useful information continues to flow.

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

If you were feeling a void in your heart for some more testing since chapter 5’s lesson on TDD, then chapters 7 and 8 are sure to get that blood pumping organ to swell.  Chapter 7 is called “Acceptance Testing” and focuses on how to determine when a programmer has completed a requirement.  Chapter 8 is called “Testing Strategies” and focuses on the “The Test Automation Pyramid” which I provided below.

In chapter 7, Robert C. Martin gives his “Definition of Done” which is accomplished when “all code is written, all tests pass, QA and the stakeholders have accepted.”  Just today our development team drafted our own Definition of Done.  Ours contains slightly different criteria as we are not engaging in TDD.  Additionally, due to our constraints, do not have the time or resources in order to produce automated acceptance tests as Martin suggests.  He focuses immensely on how integration testing through a continuous integration system is the best form of communication between programmers and stakeholders.

In chapter 8 Martin focuses on test coverage.  He believes that unit tests should cover 100% of a programmer’s code, although he admits that 100% coverage is unrealistic.  He also suggests component tests should cover about 50%, integration tests about 20%, and so forth.  Martin suggested, once again, that he believes that QA should find nothing wrong with the software that they are reviewing.  However, in this and the previous chapters, he explains that QA has the responsibility of writing the acceptance tests in conjunction with the stakeholders.  Therefore, if QA does a good enough job, and programmers ensure that their code passes these tests, then I finally agree with Martin. There exists a slim possibility that programmers can ship code to QA with some confidence that there exists no bugs in the code.

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

Unfortunately I have not done much since my blog post last week.  In fact, since our sprint finished on Thursday, my learning has been put on hold.  In light of that fact, the structure of these blogs will change.  Instead of weekly posts, I will be posting every two weeks, when our sprints finish.  In retrospect these past three learning reflection blogs were rather unproductive, but the future posts will contain much more useful and interesting information.

As I said, we completed our first sprint on Thursday.  So now I have experienced the entire sprint cycle, and I must say, it went pretty well.  Future sprints will certainly be more involved, but I think that our group handled the process without any major problems.  As this semester progresses I anticipate that our group will embrace the sprint cycle and scrum as a whole.

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