Matt on Rails

One of the things that has been nagging me as rails has gone threadsafe is how to do something like store the current user. In non-threadsafe rails, you just store the user id in a class variable or global variable, and you’re done. In threadsafe rails, you end up with obvious concurrency issues from doing that.

The logical place to store the information is in the current thread’s context. That works well for most cases, but what happens if you want to spread work out across threads? And what if those threads need the information in the thread context?

A possible solution is to create a sub-class of Thread that copies parts of the thread context to the new thread’s context. This ended up being pretty easy to do, so I tossed up an example on gist. Here’s the core of it:

class ContextCopyingThread < Thread
  def initialize
    self[:x] = Thread.current[:x].dup
    super
  end
end

Being tech lead on projects means that I frequently am asked to break feature or change requests down into development tasks. I also frequently get asked by other leads how to break work down. Explaining the goals is easy, but explaining the process is a bit more difficult.

First, the main goal is to get the work consistently sized. It makes metrics more meaningful. Two day tasks has seemed about right in the past… it keeps the metrics flowing, but it shouldn’t introduce too much overhead. It’s also nice to have bite-sized pieces so that it’s easier to stay focused and to say when the task is done. It’s also nice to have the tasks break on client-visible functional boundaries so that a release could happen between any two tasks. And, smaller tasks are almost always easier to code review. So I shoot for small-ish, consistently-sized development tasks.

So, how to explain my elite ninja work-breaking-down skills to others? When I size them by whether they “feel” like they’re the right size, I obviously don’t have something tangible to pass on.

A little while back, I read about using BDD-style stories as a mechanism for describing the functionality, which should then be pretty easy to analyze to see if it’s the right size. Still, it’s pretty much a “does it feel right?” approach.

So today, I was thinking that another way to objectify the goal, and possibly make it easier to learn to break down work, is that development tasks should result in no more than 5 significant methods and changes to no more than 4-8 files. Those numbers probably aren’t quite right, but they should be ballpark. This rule of thumb is derived from one of the benefits of small amounts of work, so it’s pretty indirect. Maybe this will be a helpful way of describing work breakdowns to other leads?