Sunday, March 29, 2015

Book review: Tunnel In The Sky

Another one of my recent reads was Tunnel In The Sky, by Robert Heinlein.  This was a book that I tried to read in junior high, but could never really get into.  The problem was that I was supposed to do a book report on it.  As a result, I turned in a book report that was full of good information about the very beginning of the book but that resolved into something completely made up by the end.  Apparently, my junior high English teacher had not read the book either, because I still made an A on it...

OK, back to the book review.  :-)

This was another audiobook from Audible.com.  The recording was high quality and well-performed.  This was a cast recording instead of a single narrator, and that format typically isn't my favorite because the interactions don't seem all that great.  This time, however, the cast worked really well with each other, and the multiple-narration wasn't distracting at all.

In addition, there were some musical transitions.  These tend to annoy me, because the editing of the music itself and its insertion as transition are typically handled REALLY poorly, making me want to saw my ears off with the spoon with which I'd just gagged myself.  This time, I was very pleasantly surprised that the music was well done, well edited, and facilitated sensible transitions between narrative sections.

4.5 out of 5 stars for the audiobook performance.

For the book itself, I liked it but it didn't knock my socks off.  For some reason, I expected more science fiction out of it.  It tells the story of a group of young adults that are being tested for survivalism on an unknown, but Earth-like, planet.  The test is supposed to last from two to ten days, but something (predictably) goes wrong.  The rest of the book is about the "natural" results of the "something's gone wrong" event.

This book came out in 1955, within a year of Lord of the Flies (1954).  In my opinion, LotF does a better job at telling the adolescent/young adult survivalism story.  Still, I can see where The Hunger Games got a bit of its inspiration, with Tunnel in the Sky having the superior story in every way.  Hint: don't read The Hunger Games beyond the first novel; on the other hand, feel free to read this book.   I certainly enjoyed it enough to recommend it.  :-)

3.75 out of 5 stars for Tunnel in the Sky as a novel.

Sunday, March 22, 2015

Book review: Gulliver's Travels

I recently finish Gulliver's Travels (using both the audiobook and the kindle version), and I must admit that I was more disappointed with it than I should have been.  I understand that Jonathan Swift was a political satirist, and the greatest prose satirist of his time (and perhaps ever).  With that said, I found Gulliver's Travels to repetitive at best.  He used four different stories to say the same thing -- human society is terrible, and we ought to be ashamed of it.  Note that the novel is set in 18th century England, and I think a lot of his criticisms are still valid.

The bit that perhaps drove me the battiest was that the main character's family was a complete afterthought.  Gulliver didn't seem to care about them at all, which is perhaps also part of the satire, but I think had more to do with the time period and setting.  It was something that I simply can't relate to at all, and made Gulliver extremely unsympathetic and non-endearing.

One technical note: the audiobook recording was very good.  It was the David Hyde Pierce-narrated version.  The kindle book, however, ended after the third section -- it did not include the story of the Houyhnhnm.  Inexplicable.

Ratings:
Story: 3 stars
Audiobook recording: 4 stars
Kindle version: 2 stars

Overall, 3 stars.  Again, I'm disappointed that I don't like it more, but not all classics align with every person's preferences...

Sunday, March 15, 2015

Agile guest lecture series: Methodologies

I'm going to wrap up this series with a quick comparison of the two most common Agile methodologies: Scrum and eXtreme Programming (XP).  If you missed any of the other three entries, you can find them at: ManifestoPrinciples, and Pragmatism.

So... methodologies.  In my opinion, the biggest difference between Scrum and XP is in their prescriptions.  Methodologies prescribe things, meaning they have sets of rules about things that you must follow in order to declare that you're adhering (cohering?) to the methodology.

Scrum

Scrum prescribes three things: roles, ceremonies, and artifacts.  Roles include Product Owner, ScrumMaster, and Scrum Team.  Ceremonies (meetings) are Iteration Planning, Daily Scrum, Review, and Retrospective. Artifacts include Backlogs, Burndowns, and (most importantly) Working Software.  Wikipedia has a decent overview of the software development life cycle using Scrum.

I spend a good deal of time talking about Product Owners, Backlogs, and Working Software during this part of the lecture.  It's important that the students understand the Product Owner role so that they know how to manage expectations -- both their own and those of the client sponsor that is filling the role.  I also remind them that they have another Product Owner in the class instructor (see the Principles lecture notes).

Backlogs are important to the students because they will become communication tools as well as information radiators.  Working with the instructor and with their client sponsor to elaborate and prioritize stories makes the project more visceral and manageable for them.  Also knowing that you don't have to keep the entire project in your head all at once is relieving -- you only need a lot of information about the stories near the top of the backlog.

Working software is the most important thing the students can produce as a result of their efforts.  I remind them that in order for it to be declared "working" it ought to be in the client's production environment.  It can't be working on their laptop only unless they intend to give their laptop to the client and help the client wire the laptop into their production environment.  Most of the students look at me like I'm crazy at this statement, and I'm glad they realize the absurdity of the scenario. :-D

eXtreme Programming (XP)

XP prescribes practices.  In fact, it prescribes lots of practices, but I generally only mention 4: test driven development, pair programming, continuous integration, and collective code ownership.  Again, have a look at handy dandy Wikipedia for decent overviews on the definition of each.

I typically only spend a couple of sentences on each of the above four practices.  The main reason for this is that software development as a craft is not the focus of this class -- project management is.  However, I make easy suggestions around TDD and pairing to make sure the students understand that these practices can help them make decisions, keep moving forward, and increase their code quality without a lot of effort.

The final point I leave them with is that they are very likely to encounter prescriptions from both of these methodologies being enacted at the same time without giving credit to each other.  There are a lot of high-functional cross-functional project teams that are gathering around an iteration backlog everyday to answer three questions that then break off to pair program using test-driven development so they can commit code to a continuous integration server that don't realize the last three things I said having NOTHING AT ALL TO DO WITH SCRUM.  Those are, in fact, XP practices that the team has adopted.  If they happen to get into a Scrum team in the wild that is not doing those practices, they have an immediate opportunity to improve the team by suggesting them. :-)


Saturday, March 7, 2015

Agile guest lecture series: Pragmatism

Welcome back! In part 1, I introduced the Agile Manifesto. In part 2, I talked about the first four principles that help fulfill the manifesto. The next thing we cover with the students is pragmatism. Specifically, I tell them to identify and do the hard work first.

The good news for the students is that by this point in the lecture we've already talked about at least some of the hardest work that they haven't thought about at all up until this point: deploying their code to the client production system. It's especially difficult because there may be parts of it that are completely beyond their control. Coordinating with client personnel that aren't normally involved in the project, working through whatever release activities are necessary for the client to get code promoted to production, adding IP addresses to whitelists in firewalls, and the like are just some of the things that will be done primarily by people other than the student teams, and as such those activities might be hard or time-consuming from the calendar perspective.

Speaking of calendars, I like to back into a few dates to instill a sense of urgency in the students at this point.

(Note that the lecture was given on March 2nd.)

The calendar begins without the highlighted dates. The first question is: Who knows when everything is due? Typically only one student out of both sessions will know the due date (May 14th, for this year's students). The second question is: Who knows when you should be principally finished with all the work? When is the code complete date? No one ever remembers this date (April 22nd). A more interesting question is why is that the code complete date? It's mainly because the intervening weeks are full of meeting other graduating student obligations, so the instructors want to make sure the students have done most of the work before the nuttiness ensues.

Both of these dates, by the way, are in the syllabus. The instructors have gone so far as to make the entire schedule into a Google calendar so that the students can easily import the dates.

The final date (or first, chronologically), is a suggestion I make for the students. If there's still hard work to be done after that date, the project is in jeopardy. The scary thing about that date is that it's roughly a month after the date of the lecture. At this point, most of the students haven't actually started working on the project itself yet. I urge them to go ahead and start making a backlog of things that they know will have to be done (either because we've talked about it or because it's in the syllabus). From that list, make a guess at what the hardest or riskiest things are and push those to the top. Go over the list with the instructors to vet it with them.

What's a backlog, you ask? That's a good question... one we'll cover in the next post. :)