All day, every day!

I'm finally back to life and reality.  The past couple of weeks have been interesting to say the least.  To begin with, at the end of April we took a trip to Utah.  Specifically, we took the REI Adventures trip to Arches and Canyonlands national parks.  Hopefully before too long we'll finish processing all of the pictures and publish some of them for your edification.  In the meantime, take my word for it that it was a fantastic trip, full of remarkable sights.  I also learned a few things.

First of all, you should start getting fit early in life and keep that habit forever.  Ten out of twelve of the other people on this trip were older than us, most of them having already retired.  All of them were in better hiking shape than we were, and we thought we'd prepared at least an adequate amount.  These folks hike regularly for the fitness and fun of it.  The life lesson here is that fitness is far more important than most people realize.  Don't continue to give it lip service.  Make it as important as everything else you do regularly.

Secondly, the people you vacation with are just as important as the destination itself.  The folks we met were interesting, funny, and kind to a person.  Our guides, Chris and Ashley, worked 16 hours a day to make the trip as enjoyable for us as possible, and they succeeded.  Well done, everyone!

Two other interesting things about the trip: one of the guys there was a Joseph Campbell fan, so I got to talk about that with someone.  I also nabbed a really neat Chinese poetry book while in Utah, and have been going through that bit by bit.  (Aside: Tanya doesn't understand why it's considered poetry, since in Russian there are REALLY strict rules about what can be considered poetic --big surprise! ;) )  Both of those reminded me that I need to spend a little more time extending my spirit (as well as my mind and body).  Make the most with what you have, then stretch a little farther!

After returning to the real world, I took on the role of "lead/point person" for our development group at work.  You might recall that a month ago we had an event that I was struggling to deal with.  I still struggle with it, but I'm moving forward at this point.  Hopefully my taking this position will keep the really talented technical people solving the hard problems while allowing me to facilitate, coordinate, communicate, and any other "-ate"s that are necessary to help make us successful.  I'll still do technical stuff too, but probably not as much as the other devs.

Another good thing that we discovered last week is that we're closing deals at work that will keep cash flowing.  While these deals aren't moving our product offering forward much, they are keeping the doors open and the lights on (so to speak).  It sounds like we'll be viable until at least the end of the summer, and very likely the end of the year, if nothing else changes.  This might sound scary to a lot of people, but it's actually really good news from a start-up perspective.  It gives us runway to sell our products and help define our niche.

I feel better about where I am in this world than I have in a month, and I'm very glad to feel this way.  The moral of the story here: remember to live life!  All day, every day!

Book Review: Off To Be The Wizard

On a recommendation from Tony, my good friend from Oztin, I read (audible'd) Off To Be The Wizard by Scott Meyer.  Tony compared it favorably to something in the vein of Ready Player One by Ernest Cline.  It took a bit for me to warm to this book, oddly enough because of the comparison to Ready Player One.  As it turns out, they are only similar in a couple of ways, and the things that I liked most about Ready Player One are generally absent from Off To Be The Wizard.  Once I resigned myself to the fact that they were, in fact, very different books, I quickly began appreciating Off To Be The Wizard as a good book on its own.

I'm not one to give spoilers, so I will avoid doing so here aside from saying that it has to do with a modern day college age guy that is transported back to medieval England and tries to become a wizard there.  Suffice to say that not only is this book a very enjoyable read, I liked it well enough to buy the next two books.  I'm trying to mix in some other material, but I will begin Spell Or High Water before too long.

Content: 3.75 stars.

And, as audible appears to be my primary consumption vehicle, I found the recording to be VERY high quality.  Luke Daniels (the narrator) did a fantastic job with differentiating between all of the main characters.  I was never confused about who was talking, and felt the intonation and characterizations were really well done.  He narrates the other two books in the series as well, and I'm very much looking forward to them.

Recording: 4.5 stars.

As an aside, I just checked, and it looks like Luke Daniels is a prolific narrator.  There are about 313 recordings on audible.com that he's participated in (if you believe their search results).  The first was back in 2009.  This might mean that he's read as many books aloud in the past few years as I've read in ANY medium.  Then again, I think he's getting paid to read them.  I wonder how much voice actors retain of the books they read...?

Still here...

This post marks the end of several things.

First of all, it marks the end of the gap in posting frequency.  I was really trying to hit at least one post a week, but the weekend of Easter ended that streak.

Secondly, it marks the end of the best times at Outpace.  You see, for the past year and a half I've been working with the most talented team I've ever seen assembled in one place.  The Thursday before Easter weekend, 60% of the development staff got fired as a result of sudden and unexpected revenue issues.  I dodged that axe, as did Tanya.  Even so, I struggle to describe the sense of loss I'm still feeling even now.

It's strange to realize how much I care for my (now former) coworkers considering we are a 100% remote development shop.  I feel their absence very keenly.  It's been really difficult to forge ahead knowing that they won't be here to help shoulder the load.

Don't misunderstand me -- both Tanya and I feel extremely fortunate to still be employed, and working with some truly superb people.  I just didn't expect to be affected as severely as I have been.

I'm not sure why, but this poem came to mind this week.  Take it for what you will... I happen rather to like it.  :-)

“You darkness, that I come from,
I love you more than all the fires
that fence in the world,
for the fire makes
a circle of light for everyone,
and then no one outside learns of you.

But the darkness pulls in everything:
shapes and fires, animals and myself,
how easily it gathers them! -
powers and people -

and it is possible a great energy
is moving near me.

I have faith in nights.”


― Rainer Maria Rilke

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.

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...

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: Manifesto, Principles, 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. :-)

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. :)