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.
Tasks that fall into this category are things like code-refactoring which will allow a sustainable development pace, or crating monitoring charts or other monitoring tools which allow developers to see how a system is behaving, but may be Greek to a non-developer. These are the things that are important to developers, that help us exact our expertise on a daily basis instead of guessing. It is equivalent to market research before making a decision on how to proceed on the business side.
However, our time is to be accounted for. We insist that the client uses a backlog with priorities, and the only thing that keeps those priorities useful is that we as developers honor them. If we venture off the reservation, then the client sees his tasks sitting around in the backlog while we do as we please.
The workarounds look like this:
Each one has its own flaw. Doing tasks outside of work hours goes against the “sustainable pace” principle. It also usually means that someone is soloing, meaning that knowledge isn’t transferred, and now you’ve got code-ownership whether you wanted it or not. Slicing out a chunk of the day and working on things in stealth way hides things from the customer, which leads to a breakdown of communication and trust. Talking to the customer sounds great, but as mentioned, it can be hard to assess value of such tasks, and ultimately, the customer will either simply trust you that this is important, or he’ll decide that you’re over engineering something and deny you the freedom to do technically critical tasks.
You could argue for the developers to be assigned a “budget” each iteration for development tasks. That’s not half bad in principle, because now the developers have some freedom, and they also have to prioritize what is and is not important. But then, what do you bill against that budget? Does all testing go against it? What about the time spent setting up a server in a repeatable way? Where is the line, who draws it? This system gets complex and contentious very quickly.
The only solution I’ve found: People. These tasks have to get done because they “fell” important to the developers. The developers experience pain points, and can anticipate when certain design choices will impede future progress. They will solve this problem on their own, but one situation solves the problem more than most: Have someone develop with the team who owns the backlog. He may be a “junior” developer, and he may spend a significant portion of his time tending to business tasks as well, but he will feel the same development pain as the rest of the team if he is in it, pairing, and hearing the groans of “this should be better” or “this will bite us in the future”.
No methodology, be it Agile, Waterfall, or anything else I’ve heard of, accounts for this person. It is a treacherous line this developer-business hybrid walks. Too much development, and he risks becoming out of touch with the business goals. Too much business, and he risks being alienated from the development team.
Developers need this person. They need someone who will hear and understand their technical needs, and still be able to temper their work with the business goals in front of the company. Without him, you create complexities too great for any system to handle, or you run the risk of breaking down the lines of communication.
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.
It seems like a one pair project has it easy when it comes to knowledge transfer. Of course what it gains in simplicity, it also lacks in variety. That aside, it’s really easy; the client talks to the pair, and only two units need to be on the same page, one client unit, one pair unit.
The growing pain is easily identifiable when jumping to two pairs. Now the two pairs may agree, but the client may be picturing something else. Or maybe only one pair went on the phone call on Tuesday, so the Thursday phone call is different for everyone because they don’t all have the same context.
But it isn’t that hard to put four people on a phone call and have everyone ask enough questions to be heard and to understand. At six, now we’re talking about a lengthy discussion. Coming to a democratic consensus also becomes exponentially harder, let alone getting unanimous support. That’s OK, it is the disagreement that makes us pause just long enough to do the right thing, but it also means someone gets left out.
Going from two to four, then to six also means that you can get more work done, a lot more. How will you feed them this work? With one pair you can easily go day-by-day with just a few story lead time. When you get to three pairs, and each pair is blocked on one story, waiting for a batch job on a second story, and looking at the backlog for a third, you can’t go too long before you find yourself in a full on planning meeting on a very regular basis. Suddenly, keeping the backlog in order and stories teed up to be worked on goes from something you do at the end of the day to a full time job.
What one pair can often accomplish inline with a client, two pairs can do with some structure, but three pairs need to have a sit down and a real opportunity to have open conversations. That is not say, “Three is bad, never go above two pairs.” I’d argue for quite the opposite in fact. Three pairs have helped us flesh out how we really work, brought more areas of improvement to light, and of course, delivered more business value than ever before.
The real point is to say, “Be ready.” Our client knew this from experience, but it can be a hard lesson for a budding start up. You can try to be the head of sales and a project manager of a team of eight, but you’ll soon find yourself likened to “butter spread over too much toast”. As you grow your development team, you can also be prepared to grow your resources dedicated to keeping that team informed, fed with stories to work on, and reviewing the one’s they’ve completed.
*”Proxying Apache to Thin and getting 502 errors.”
Beware: Health check ping every 3 seconds * 15 mongrels * 1 week = millions of session rows. Create skip_filter entry for your health ping action.
Snow Leopard 10.6.2 is out. An unlucky upgrader attempted to go 10.6.1 -> 10.6.2 and it hosed the machine. This required the upgrader to reinstall Snow Leopard from disk, then upgrading to 10.6.2. Backup your data before upgrading!
Redefining an aliased method may not do what you expect: When the aliased method is invoked the original implementation executes.
def do_something puts "hello" end alias :do_something_else :do_something def do_something puts "goodbye" end do_something_else # prints "hello"
Yesterday I modified an old app to turn off a feature for records that were more than a certain number of days old. This is an old enough app that the test data is still yaml fixture files, and in the fixtures I see records with attributes like so:
published_at: 2006-08-25 00:00:00 -07:00
created_at: 2006-08-24 00:00:00 -07:00
updated_at: 2006-08-25 00:00:00 -07:00
And of course, the tests code also makes assumptions about absolute dates…
get :show, :year => '2006', :month => '08', :day => '24'
assert_not_nil assigns[:article]
That makes adding tests that need to check for dates relative to the current date very difficult to integrate into the test suite. It also means that over time, your fixture data gets “stale” and you don’t have any data that appears to be recent, which may or may not matter to your application.
One way to deal with this is to mock time in your test code, so that tests always run at the same effective time, so the hardwired absolute dates in fixtures are always relatively the same age. I think that’s a good Plan B, but I prefer Plan A.
Plan A is to create your test data with dates and times relative to when the tests are being run. You can do that in yaml fixtures by embedding ruby in the yaml:
published_at: <%= 2.days.ago.to_s(:db) %>
created_at: <%= 3.days.ago.to_s(:db) %>
updated_at: <%= 2.days.ago.to_s(:db) %>
And in your test code, be flexible too:
pub = article.published_at.to_date
get :show, :year => pub.year.to_s, :month => pub.month.to_s, :day => pub.mday.to_s
assert_not_nil assigns[:article]
Keep your test dates relative, and a year from now you’ll thank yourself (or somebody else will).
“We’re getting id’s from facebook that are overflowing INT columns in mysql tables. Should I use BIGINT to accommodate these ids? Is this wasteful?”
Use string columns instead. VARCHAR columns will only use as much space as the id needs.
“Are VARCHAR columns slower to join than INT columns?”
Not in mysql. Strings do not have join performance penalty compared to integers.
Edward was a guest lecturer for a Carnegie Mellon University course where students are learning to do Agile development. Course work involves pair programming, TDD, and using Ruby on Rails. The talk was well received and Edward is invited to come back next year!
There is an apparent rails bug (2.3.2) when building associated objects and then saving them.
class User < ActiveRecord::Base
attr_accessor :bool
before_validation_on_create :set_bool
def set_bool
self.bool = true
end
end
class Child < User
belongs_to :adult
before_validation_on_create :create_adult
def create_adult
if adult.nil?
self.build_adult()
end
end
end
class Adult < User
end
specify "should work" do
child = Child.create!()
child.bool.should be_true
child.parent.bool.should be_true #fails
end
For the past few years, Pivotal has had a mustache growing contest in November. For a month, upper lips got stubbly, then fuzzy, and in some cases down-right bushy. Much trash was talked and then awards were given & eleven months of bragging rights began.
Last fall, my sister-in-law asked if our competition was tied-in with the fund raising of Movember. We weren’t. She told of how her entire office got involved and had a big party at the end of the month and they raised a whole bunch of cash to fight, lightly put, “dude cancer”.
(Well most of them did – she told me about one guy who, when a much-delayed blind date finally got scheduled for November Movember 28th, he bailed & shaved before the big ‘meet’. Serioulsy?First impressions are important, but if the date can’t deal with the ‘stache for a couple more days in the name of cancer then they’re likely not “material”. But I digress…)
So this year Pivots are growing mustaches for Movember and nearly a third of eligible upper lips are participating. There are a few different competitions going on and I wanted to catch you up on progress at the end of week one.
In the team competition we have Pivots-West – those in the San Francisco office – growing against Pivots-East – the New York City office. The team that raises the most money per ‘stache will win a pub lunch, a trophy for their Pivotal office, and bragging rights for a year. We have various ad-hoc individual awards that we’re working out as well, but more on that later.
As of Movember 8th:
All the money is tax deductible and goes to the Prostate Cancer Foundation and LiveSTRONG. We encourage all of our regular readers, and really, the whole Rails community to donate:
If you’ve already donated, then thanks! Once you’ve donated and are curious as the whisker progression, then please check out our Photo Blog.
That’s all for now. See you next week for another progress update…
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.
This sounds like a great branching situation to me. I am not a fan of “feature branching”, it relies a lot on humans doing the right thing. Check out A, make changes, Commit, Check out B, Merge, Commit, or some similar pattern. Then you start another feature, but wait, you made half your changes and you forgot to start a new branch, no you have a quasi-tangled mess. It can get real ugly real fast. But one branch created for a specific length of time doesn’t sound unreasonable.
The opposition is pushing for no branch, and various flags littered throughout the code to. I’m sure you can tell by my use of the word “littered” how I feel about this idea. It makes the code more complex, “What’s going on here?” “Is development doing the same thing that production is? I don’t know, we’ll have to go look at the config file”
And what happens when we change our crontab template? Are we going to put flags around the old schedule and the new one? What if I forget? What if I take out something that we no longer need as we develop, but was key to the old stack? So now I’ve got to run (and write) tests to cover two environments to cover my human frailty. My test suite is now 2x longer.
Branching in this case should be an easy sell IMO.
Code levers are cool in some situations too. We made a large undertaking to change the way our servers keep themselves up to date. Previously we made large scp calls to literally copy the entire set of data out to the slave servers. This happened a few times a day, and makes for long delays on updates. We have taken small chunks of time over the last few months to put a queuing system in place, so that updates can be made as soon as they are processed. During these months, both systems had to exist side-by-side. We could have mad e a feature branch, but it would have meant keeping the queue branch up to date all the time and dealing with merge conflicts all over the place. The switch is great because it is just one feature, I can write tests that enable the queue and test it out, and I don’t have to worry about it being neglected. The key is that there’s active development on the feature, the code lever is great here.
When I cut a branch, I want it to be a thing that is something that is basically a snapshot in time. I’ll make critical changes to that branch and nothing more. For active development, I see the merit in a feature branch, but it requires the developer’s be more rigorous in his use of version control. Whereas the code lever also adds complexity for current feature development, it happens where a developer is most comfortable, in code. Still, I’m the outlier in our branching/code lever thinking, so maybe I’ve missed something, maybe my thinking has some catching up to do.
UPDATE: We’re branching, thanks for all of the insight here and around the office
Exceptions thrown in Rails views get wrapped by
ActionView::TemplateErrorwhich makes rescuing specific exceptions hard
It’s probably best to prepare all your data in your controller or models and not in the view, which will obviate this and other problems.
There’s a new Mac OS X Dashboard widget available that allows you to create Pivotal Tracker stories easily, right from your desktop.
It’s written by Thomas Vie, and posted on his blog here:
http://techpolcook.blogspot.com/2009/11/widget-for-pivotals-tracker.html
The widget uses the Pivotal Tracker API. For other user contributed tools and applications, check out the 3rd party tools page.
