I got the opportunity to do a little road-trip with my daughter this past weekend. I had an opportunity to speak at the Carolina Code Camp. They accepted all three of my submissions, so I figured I should make the trip. She spent a couple of semesters at High Point University in North Carolina and was looking forward to seeing some friends, so she offered to come along.
The trip was great. We had a total of fourteen hours together in the car, which gave us plenty of time to catch up, talk philosophy, talk a little politics, and just hang out. If you think fourteen hours is a lot of time to fill talking, you haven't met my daughter or me. Separated, we are fairly loquacious, but together, we can get into a zone and move from subject to subject with nary a pause.
The Technical Debt Trap
I had the honor of presenting at Chicago Code Camp this week on the topic of technical debt. For those of you who know me, you know this is a topic I feel passionately about. More accurately, I am concerned about the misunderstandings surrounding technical debt and the frequent use of the term to placate any sense of responsibility over writing messy code in pursuit of a deadline.
Optimal pairing
A while back, I posted a rambling entry about the impact of Harmonic Mean on a team's performance. The post was actually about pairing. My intention was to put a solid mathematical, albeit only pseudo-scientific, explanation behind my paring recommendation, but I think I lost several people (including myself once or twice) in the math and all the fancy words.
In short, whenever you pair two people of disparate skill sets, their contribution to production is more heavily influenced by the lesser skilled or experienced of the two. And the impact is significant. The greater the disparity in skill/experience, the more significant the impact.
Stories are about why; not what or how
I've been on numerous Agile projects with varying methods for capturing stories. Quite popular (and purportedly the ThoughtWorks standard) is the "As a, I want, So that" story format.
While I have seen teams do well with this format, I think it can be radically improved with a minor change. I prefer to see "So that, as a, I want" story format.
My reasoning is quite simple; the emphasis is incorrect in the common story format.
Harmonic Mean is a Bitch
A chain is no stronger than its weakest link. Metaphorically, this applies to teams. But in actuality, this is simply not the case. Humans have not only tenacity, but the ability to countervail one another. This is a quality that inanimate objects simply do not possess. We can and will compensate for one another for the good of the team. Links in a chain are incapable of sharing their strength. No other link can compensate for the weakest.
Caution: Metrics change behavior
Measuring and reporting are important
I've often heard said, "That which you cannot measure, you cannot improve." And while I do believe this is a general truth, I think it fails to tell the entire story. It is not just about what we can measure, but what we actually do measure that is significant; "That which is reported, will improve."
Introduction To Functional Programming with Scheme
What if no one reads it?
Among the books I am currently making my way through is "Exploring Computer Science with Scheme" by Oliver Grillmeyer. The publish date on this particular book is 1998. No matter how often it happens, I feel a twinge of despair for our profession when I read sound advice from a decade or more ago that has yet to be widely adopted; or worse is still hotly contested.
Grillmeyer contrasts a couple different functions that accomplish the same end. One terse, but obfuscated; One verbose, but transparent. In conclusion, Grillmeyer states, "In a tradeoff between readability and length of code, you should favor readability."
Business Value is not the only reason to adopt Agile
Agile Rob posted a column a few days ago entitled, "If You Don’t Focus on Business Value, Don’t Adopt Agile." He tweeted it out and after reading it, I replied that I did not entirely agree. Rob asked that I post a comment on his blog. The following is an extended/modified version of that reply.
I read two articles today, "Adopting Agile Isn't The Point", by Mike Cottmeyer and "If You Don’t Focus on Business Value, Don’t Adopt Agile.", by Robert Dempsey. Rob's posting is an expression of agreement with Mike's.
Martin Fowler on Technical Debt
Martin Fowler just posted an article on Technical Debt in which he discusses the Technical Debt Metaphor. Fowler argues that the metaphor should (and does) include messy code. He talks about deliberate and inadvertent debt as well as reckless and prudent debt. Prudent and Deliberate is the most desirable. While Reckless and Inadvertent is the least desirable. He published the following quadrant to help explain his concept.
Craftsmanship
I have the profound and intimidating honor of being the fifth person to make note in the Wandering Book. To be honest, I'd hoped to be later in line. I'd hoped I could read numerous entries and ponder all the wisdom before it came my turn to write. As the fifth, I have to admit there is already a great deal of wisdom in the book. The four before me are remarkable people. And those who will follow me are surely remarkable as well.
I'd rather be in last place
I joined the cross country team my freshman year of high school. I knew nothing about the team and little about the sport, but I figured running wasn't too difficult and was certainly less dangerous than football.
It turns out the team was one of the best in the state. They had a legacy of excellence for well over a decade. They consistently won their league, placed in districts and regionals and sent at least individuals, if not the entire team to state.