Will Read's blog
A made up conversation with myself:
Let's say I have a cool service. Now I want someone to take my cool service and develop against it. So I make an API. I'm using RESTful methods in RoR so it's pretty straight forward to expose the CRUD actions. Done!
I release it in to the wild. People are jazzed, and they start to make clones and clients that do the same thing as my service. That's cool, it's driving an extra .5% of the traffic to my site. But I'm waiting for someone to innovate and blow my mind. With what? I don't know!
Well, I gave them the ingredients, and the instructions, and they took my API and made an API cake, just like I showed them to make. They can read the product catalog, or they can post messages, and they do.
The cool part for developers is the "intellectual property", the numbers in most cases. Let me get at how people are using my cool new service so I can start to make conjectures like "if A happens in the context of B, then we usually see C". Like what if I had the number of facebook status messages about a new comedy show premier, and I search those for the word "funny" and plotted them over time? I could paint you a picture of what parts of the show were entertaining. But I can't get at that kind of data.
Similarly, what if Amazon told me how many self help books were sold in New Jersey over time? Then I could make a map of where a psychologist should open up a practice.
Some of this information deals with privacy of the users. Some of the information can be anonymized, but is still too close to something the company views as a core process which is currently giving them a competitive edge. That's exactly why it is interesting, why those developers are hungry for it, why you should release it, and give your users a tremendous experience. If you set loose the data, your developers will be able to creat more than just a copy of existing functionality, they can really innovate and tell you things about your business that your customers didn't even realize.
"Bugs and Chores don't get points, unless you want to give them points, then they get points, but don't point your bugs or chores." Whaaaa?
In Tracker, you can (and should) always point your features. But you have to turn on this setting buried deep in the menus and next to a disclaimer if you want to point your bugs and chores.
If you're looking for that check box, you're probably a developer, or someone who is responsible for justifying the work of the developers. The business side has no interest in it what-so-ever. "Why?" That's the right question.
I recently returned from a trip to Egypt with Pivotal's own Lara Owen. Like all good tourists, we went and saw the Pyramids of Giza. Like far fewer tourists, we also went to Saqqara to see the Step Pyramid and then on to Dashur, home of the Bent Pyramid and the Red Pyramid.
In the 3rd Dynasty, the Step Pyramid is constructed under the rule of Djoser. The pyramid has entered the market. By the 4th Dynasty, under the rule of Snofru, six steps are no longer enough, users want seven steps and smooth sides.
In an attempt to meet these new market demands, the Bent Pyramid construction begins. Half way through, they realize they made a mistake, and adapt their plan accordingly by changing the angle down from 54° to 45°. The next attempt, still within Snofru's lifetime, becomes the gold standard of pyramids and is known as the Red Pyramid. With it's consistent sloping smooth sides and added height, this pyramid was fit for any king.
What I thought about, as you might have guessed by now, was the methodology used to construct each of these pyramids. In the case of the Step Pyramid form the 3rd Dynasty, it would be easy to see a king proclaim, "I want this kind of pyramid and I want it ready by the time I die." And he'll get something twenty years later that resembles what he wanted twenty years ago.
Snofru had a different plan. He was going to shake up the way people think about royal tombs. He was going to do something no one else had done. This man of foresight said to his people, "We will release early, and we will release often. We will have meetings along the way to reflect on how we have progressed, and we will then plan ahead only as far as is practical, adjusting as we go. Most importantly, we will trust each other such that mistakes can be made without causing great harm to the project." It was with this spirit that Snofru began work on the Bent Pyramid.
He didn't know what he was doing, there was no model to copy, no patterns to solve this problem. So he guessed 54°. And they built, and they talked and said "Hey Snofru, this looks great, but it won't be stable if we continue at this angle." To which Snofru probably replied, "I will trust your expertise here, can we make the angle less steep and see how that works out?" So 45° it was.
When the finished, they stood back and looked at the work they had done. It was taller, and it did have smooth sides, but it wasn't quite right. Snofru, being a wise king, knew that this was a great success.
- A taller pyramid could indeed be built.
- 45° was a sustainable angle
- He was still drawing breath and now had the knowledge to fully realize his goal.
Snofru still had plenty of time on his hands, and because he released early instead of letting construction drag on, he had new insight from the retrospective that he wouldn't possess otherwise. So he built the Red Pyramid with complete success.
Snofru was, in my opinion, the first adopter of Agile principles. His "employees" trusted him enough to be able to push back when the plan needed revising. He trusted them right back not to yank his chain about things being too steep. He made his mistakes up front, which taught him lessons about his domain, and it enabled him to be successful in the long run.
No matter what point scale you use to estimate stories, and if you call them "points", "gummi bears", or "t-shirts", people always want to know what they mean. The problem is that the keepers of the points don't know how to relate to the users of the points.
Joe: "Oh look a new story in the icebox!"
Sam: "Let's estimate it!"
Joe: "Sure, what's a 'one' work out to be in terms of effort/complexity?"
Sam: "That's like... half a day"
I've been in Joe's shoes, and I've been Sam too many times. Do you see the disjoint? Hint: check the bold. Joe asked about effort/complexity because those are things he can estimate with some degree of accuracy. Sam jumped to the lowest common denominator, and converted his concept of a one point story into a unit of time.
Problem: Velocity is the conversion factor from points to time. Velocity is useful, Sam is not (no offense if your name is Sam).
A "one" is what then? It varies from team to team. How do I get Joe up to speed on point values then? Common ground, relate to Joe. We've all done some programming before. Maybe a one is "a batch of CSS changes", and two points works out to "administrators should be able to edit all product fields". Then you work your way up to "make a web-based zoo" which is wherever your point system tops out because it has a lot of unknowns and/or complexity.
Relation Points, use them to relate to your fellow developers. Use them to relate to your product owners and managers. Start speaking in terms that show you've got more knowledge about the development cycle than a random guy off the street. Anyone can give you the time, but what you really want... is to get to the points.
There's an untapped cash cow out there when it comes to recruiting and her name is LinkedIn. Until recently, only LinkedIn had access to your profile and social graph, but all that changed with the release of their OAuth-based API. I'f you've hooked into Twitter or Google then this authentication process should feel very familiar to you. To help you along, pengwynn released a LinkedIn gem last week.
Developers need to do stuff that you will never ask them to do, and if they asked you if it was ok to do it, you would tell them, "Let's do something else." I'm not talking about "gold-plating" an app, or the kind of thing an "architect astronaut" would cook up, I'm talking about real value-adding tasks that are near-impossible to assign a direct business value.
When I joined the project, we went from one pair, to two. Today, we're three pairs, six people strong. But the communication paths now are far more numerous than the one pair days.
There's a debate right now in my team about how to handle a "code freeze", a debate which I find myself on the outside of the majority. The idea behind the code freeze is that one stack of our app will be "frozen" through the holiday season, with few if any changes between now and January. Meanwhile, we'll keep on developing AND releasing to a separate stack.
Interesting Things
- "... not missing constant" ERROR To reproduce this error you do something like this:
Generate a rails app, call it "test".
Create a module scoped model called Post in app/models/mumble/post.rb
class Mumble::Comment < ActiveRecord::Base
belongs_to :post
end
Create a module scoped model called Comment in app/models/mumble/comment.rb
class Mumble::Comment < ActiveRecord::Base
belongs_to :post
end
Then at the command line
$ script/console
Loading development environment (Rails 2.3.3)
comment = Mumble::Comment.first
=> #
comment.post
=> #
exit
$ script/console
Loading development environment (Rails 2.3.3)
post = Mumble::Post.new
=> #
exit
$ script/console
Loading development environment (Rails 2.3.3)
post = Mumble::Post.create!
=> #
comment = post.comments.create!
=> #
comment.post
ArgumentError: Mumble is not missing constant Post!
from /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:417:inload_missing_constant' from /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:80:inconst_missing'
Apparently, there are various situations that can cause the infamous "Mumble is not missing constant Post!" error. In this case it appears the associations do not understand the module scoping, despite the statement:
By default, associations will look for objects within the current module scope.
at http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html
The solution was to explicitly declare the class name in the association:
class Mumble::Post < ActiveRecord::Base
has_many :comments, :class_name => "Mumble::Comment"
end
and
class Mumble::Comment < ActiveRecord::Base
belongs_to :post, :class_name => "Mumble::Post"
end
Then to show the error is no longer present
$ script/console
Loading development environment (Rails 2.3.3)
post = Mumble::Post.create!
=> #
comment = post.comments.create!
=> #
comment.post
=> #
- "Rake Set Theory" when running the same thing in rake multiple times, Rake strips out the extra commands. For example: $rake db:rollback db:rollback which you might expect to preform two rollbacks, only does one rollback. This can be frustrating if you're trying to couple rollbacks with a db:test:prepare or some other logical chain of events. At the command line you can of course work around most situations by && together multiple rake commands.
This is Part 2 of my two part series on working with queues in Ruby. If you want some context please head over to part 1. In this post I'll touch on Moqueue, using RSpec to stub out Bunny, and a few other hurdles along the way.