Gamifying Pull Requests
2012 February 17
At Conversocial, we structure our work with pull requests. Each one is supposed to be reviewed by at least one other member of the team before it gets anywhere near the master branch. Adding comments to pull requests is a good way to get a dialogue going that can highlight potential problems with the code. Zach Holman posted a good summary of this working style last year.
Without much happening last weekend, I decided to create something to add a little bit of incentive and competition to our pull request process.
Version 0.1 of this system is tremendously simple. Every 10s it checks
the github API to see whether there are any new pull requests, or if any have
been updated. If that's the case, it fetches the comments and gives out points
based on their content. For simply making a comment on someone else's pull
request, a developer receives one point. If the comment contains the
':sparkles:' emoji, then the
author of the pull request receives 4 points (as long as the commenter isn't
also the author!).
Accumulated points are displayed on an LED matrix hung on the wall of our office. My hope is that this will encourage more feedback in general, as well as a way to give a colleague a little slap on the back for a clever algorithm or a nice bit of attention to detail.
That LED board is a Peggy that I made a couple of years back from a kit. It involved over 1300 solder joints, so I'm glad to see it in use again! It's only 25x25 LEDs though, so I had to economize on space.
The system is quite obviously open to gaming, but gaming attempts will have to take place in the open. Maybe we'll need to adjust the scoring and add more sophisticated measures to make it meaningful. Time will tell whether it has positive effects.
The code is on github, of course.
Art therapy for software geeks
2011 March 12
Here's a short post written while I'm still on a high from a superb Code Retreat at Eden Development in Winchester. I don't think I've ever been around such a passionate bunch of software people before. It was totally inspiring.
For me, it really felt like a retreat. A retreat from frameworks, from legacy code, from issue tracking, from release management. It was just tests and code. I tried 7 different approaches to the same problem with 7 different people in 6 different languages. At the end of every cycle, we deleted everything and started fresh.
The main point of this post is to give some Google Juice to the people who put the day together: the aforementioned Eden Development, everyone I worked with, Aimee and Despo who organized, and thanks to Enrique Comba Riepenhausen who provided constant challenges and guidance.
Humility in the face of complexity
2010 December 15
Michael Brunton Spall gave a great little talk on his debugging methods at ScaleCamp last Friday. He based it around a procedure called Analysis of Competing Hypthoses (ACH). Boiled down a bit and applied to debugging, ACH instructs you to:
- List all possible causes for a given bug. Get others to offer their own hypotheses. Don't throw any away yet.
- List what's already known as evidence for and against the hypotheses.
- Building on step 2, Decide what extra evidence you need to gather to refute each hypothesis.
- Gather it, and eliminate possibilities until you have one left.
- Profit!
I think the most powerful thing about this process is the way it forces us to falsify and eliminate hypotheses, countering the very human instinct to hunt for evidence to support our hunches. Falsification is efficent: it can often be accomplished with a single piece of inconsistent information, lasering through all the other evidence with a satisfying logical zap.
Read more...