Pete On Rails

I took the MyQuotable example code down from github for a little while because I’d hosed it up trying to convert it into a facebook application. A few users have emailed me in the past month or so asking where the code is located.

I’ve just republished the source code, so you can again download my example application for VoteFu.

Because they already know the answer to the burning theological question that has ignited fury around the globe for thousands of years.

[pete@me.local log]$ which god
/usr/local/bin/god

Scrum Masters embarking on a project or converting a team from conventional development to Scrum often run into one big roadblock: convincing the stakeholders to use Agile Estimation techniques. One of the most important and success-inducing things you can do when estimating an Agile project is to abandon the “hour” as the unit of estimation in favor of “story points”.

The idea is, instead of using “hours” to estimate how long a story will take to complete, you instead have the team use an arbitrary figure called a “story point”. So, a new input field on a web page might be “1 point”. A new login screen is probably “3 points”. And adding a new payment gateway may be “8 points”.

Each iteration will then have a point value assigned to it. For example, Iteration 6 may be “23 points”. When your team completes all of the functionality, the team’s velocity is “23 story points per iteration”. Savvy Scrum Masters will calculate Velocity as the moving average of the last 4 iterations.

Why bother ditching the “hour”? Here’s why:

1. It eliminates preconceived notions about how much code can be written in a day.
2. It eliminates the “Day” as an important unit of measure.
3. It forces you to forecast completion of your project based on evidence. If you estimate in hours, you’re already forecasting. If you estimate in points, you’re simply measuring complexity in relative terms and relying on past performance to predict future results. In software, that’s a good thing.
4. It helps to gel the team. If Joe can do a feature in 8 hours, and Eric can do that same feature in 12 hours, there’s going to be a disagreement on how much to estimate. Instead, shouldn’t Joe and Eric agree that “Two new fields on the screen is twice as big as one new field on the screen?” Over time, the difference in coding productivity between your team members will be abstracted away by the estimation technique, which allows each team member to play to their own strengths without being measures in widgets-per-hour.
5. It ends up being more accurate after 2 or 3 iterations.
6. It avoids the mythical man month problem. By insisting that you forecast based on evidence, a manager cannot offer to double the team size and cut the deadline in half.

There are lots more benefits. There are books full of the benefits. Read them.

In convincing stakeholders to allow the engineering team to use Story Points, I have run into several objections. Here they are, along with the answers that I use.

Objection: But if your numbers don’t map to hours, how do I know how long something will take?

Answer: You use Velocity, as calculated by the evidence of progress your team produces, and map target dates based on what actually happened instead of a gut feeling.

Objection: But then how do you know how much more you can get done by adding more resources to the project?

Answer: Again, you use the evidence. Adding a new team member doesn’t immediately produce a faster tempo on a project. There is no way to know how a new team member will contribute to a self-organizing team until you see them perform. As that team member ramps up, the team will eventually start producing more story points per iteration. You will only take on work in a sprint that you historically could complete, and as you start completing all of the committed work faster, your velocity increases. The team is continually winning instead of lagging. If you instead use “hours” to estimate, you’d be tempted to just add “40 hours” to the velocity. That’s a guess, and it’ll be wrong every time.

Objection: But then how do I calculate what a project costs me?

Answer: If you have all of the members of a Scrum team properly allocated, and you have an accurate forecast of the completion date, then you can easily calculate the project labor cost using very simple math. If you use hours instead, you use the same simple math, it’ll just be inaccurate.

Objection: But then how do I know how much overtime to ask the developers to work in order to meet my deadlines?

Answer: Forcing overtime to meet deadlines is a Scrum Smell. It means you are planning poorly, sticking to unreasonable deadlines, sacrificing quality, or the team is failing because of some organizational, process, or performance issue. That said, it is sometimes necessary to work overtime. Rather than tell everyone they need to work 10 extra hours this week to make the deliverable, it’s actually BETTER to say to your team: “We have 10 more story points to complete in 2 days, and we’re only burning 3 points per day.” If the Scrum Master is good, the team will know what to do. And they’ll do it as a team.

Good luck! Let me know how it goes.

A number of VoteFu users have asked me for help integrating VoteFu into their codebase. I recognize that this means I’ve probably left the documentation lacking in a couple of places, but in order to immediately help those folks who want a reference implementation of VoteFu, I am releasing the full source code of MyQuotable.com.

MyQuotable was a fun distraction for me, but frankly, I really wrote it so I could have a POC application for VoteFu and a couple other plugins. it doesn’t have any particularly useful Intellectual Property and it’s not the Next Big Thing. So it doesn’t make sense to keep the source closed.

You can get the source code from GitHub.

I saw this posted on Jacqui Maher’s blog today and was so amused I had to reblog it.

if (!(typeof worldHasEnded == "undefined")) {
   document.write("YUP.");
} else {
   document.write("NOPE.");
}

From http://hasthelargehadroncolliderdestroyedtheworldyet.com/.

Aside from the very obvious “you don’t need to negate that test condition, just reverse your simple if and else clauses” issue, it’s quite amusing.

Clever. I like it.

A couple of contributors forked VoteFu and submitted some patches. I’ve updated the master branch to integrate the changes. Notably:

• VoteFu now works as a standard gem in a Ruby application. (i.e. not as a Rails plugin)
• VoteFu now works as a Rails Gem Plugin.
• VoteFu now works with Rails 2.2.2.
• Other assorted small bugfixes.

To install VoteFu as a Gem Plugin:

sudo gem install peteonrails-vote_fu

Then in config/environment.rb:

  config.gem "peteonrails-vote_fu", 
     :source => "http://gems.github.com", 
     :lib => "vote_fu"

And then, optionally:

rake gems:unpack

Special thanks to Jon Maddox and Bence Nagy for the updated code. Check it out yourself!

Picture of a cute kitten attacking unseen prey

I absolutely LOVE the cover of this book. And the book itself looks pretty decent, though how the author fills 300 pages with tricks and tips on Ubuntu it beyond me.

I’m not sure when it happened, but the technical world starting using amusing pictures of animals on the covers of their books some time in the late 1980s or early 1990s, and they seem to be the only ones I can remember. I’ll bet they typically sell well too.

The first book I can remember buying in this genre was the Pink Camel Perl book in 1995 or so (it was published in 1991), with a picture of a camel on the front. This book proved to be a long-lived reference guide for me, and now I hold onto it for sentimental value. Interestingly enough, I’d never have been able to tell you the name of the book, which is “Programming Perl”. Here is a picture of it:

Oddly, O’Reilly kinda blew it with Ant: The Definitive Guide. It has a picture of a lizard on the front. What’s that about? Wouldn’t you put a picture of an Ant on the cover of this book?

Compare those three covers with these covers, from two of the most important and influential books in programming:

Boring! But again, these are two very important books based on their content. Care to wager how the relative sales numbers of the Camel Book and K&R look?

I don’t like to write about politics. However, I am glad to see that I am not the only one who thinks of Bob the Builder every time I hear Barak Obama say, “Yes we can!”.

I really like the app on AngelSoft’s new homepage.

A long time ago I created an app that would post messages to the homepage in a ticker when site visitors would do stuff. It was for a liberal political action NGO. From the homepage of this NGO’s site the ticker would flash messages like “A member just sent a fax to Senator Jim Webb about Senate Bill 1022″ or “Bill Jones just became a new member. Welcome Bill!”

I like how they’ve taken that concept and put it on a map. Nice.

Funny how we forget cool ideas from long ago. And funny how we forget that there’s always a chance to build off of old ideas to create newer, better ones.

Great work, AngelSoft. I expect to see a lot of people follow suit.

Microsoft has been issued a patent on Page-Up/Page-Down functionality (see below). I was annoyed when Amazon patented One-Click-Checkout, but this patent is even more troubling. I have written about Patent craziness before, mostly as it related to “Submarine Patents” (i.e. patents for products that will never see the light of day, to the benefit of the patent-holder).

This tactic is somewhat different. It patents an industry standard that has been in effect for a long time. 30 years ago, computers had page-up and page-down keys on their keyboards. It seems a little late to be seeking protection for such an innovation.

Anyone know the prior art backstory here?

From the FreePatentsOnline

A method and system in a document viewer for scrolling a substantially exact increment in a document, such as one page, regardless of whether the zoom is such that some, all or one page is currently being viewed. In one implementation, pressing a Page Down or Page Up keyboard key/button allows a user to begin at any starting vertical location within a page, and navigate to that same location on the next or previous page.

For example, if a user is viewing a page starting in a viewing area from the middle of that page and ending at the bottom, a Page Down command will cause the next page to be shown in the viewing area starting at the middle of the next page and ending at the bottom of the next page. Similar behavior occurs when there is more than one column of pages being displayed in a row.