If you have ever been in an Agile project, or something that looks like it, you should have heard about the concept of spikes.
For those who haven’t, spikes are the agile response to reducing technical risk in a project. In case you are not sure how to build something or fear that some piece of functionality might take much more than expected, and you have to gain more confidence about it, it’s time to run a spike. Usually timeboxed, spikes are technical investigations with the objective of clarifying a certain aspect of the project.
In my current team, we are developing a few tools that are quite specific to our context and were not sure on how to solve a few issues, so we have been quite frequently playing spike cards.
This is all not new and I’m sure most of you have done that before. If you did the way I used to do, you would write a spike card, something as “investigate technology X for problem Y“, would spend 2 days doing it and would have a response for it in your head once you were finished.
In our current context, team members were rotating quite quickly, so we were worried that any knowledge we would get from spikes could have been lost if it was just…let’s say.. in our heads.
Not wanting jut to write the findings up, as we first thought about doing, we decided to tackle the problem with the golden hammer of agile development: tests!
So, instead of writing tests to decide how we should write our code, we started writing tests to state the assumptions we had about the things we were investigating, being able to verify them (or not) and have an executable documentation to show to other people.
For example, here is some code we wrote to investigate how ActiveRecord would work in different situations:
it 'should execute specific migration' do
CreateProducts.migrate(:up)
table_exists?("products", @db_name).should be_true
table_exists?("items", @db_name).should be_false
end
it 'should execute migrations to a specific version' do
ActiveRecord::Migrator.migrate(ActiveRecord::Migrator.migrations_paths, 02) { |migration| true }
table_exists?("products", @db_name).should be_true
table_exists?("items", @db_name).should be_true
table_exists?("customers", @db_name).should be_false
end
it 'should not execute following migrations if one of them fails' do
begin
ActiveRecord::Migrator.migrate(ActiveRecord::Migrator.migrations_paths, nil) { |migration| true }
rescue StandardError => e
puts "Error: #{e.inspect}"
end
table_exists?("invalid", @db_name).should be_true
m = ActiveRecord::Migrator.new(:up, ActiveRecord::Migrator.migrations_paths, nil)
m.current_version.should == 3
table_exists?("products", @db_name).should be_true
table_exists?("items", @db_name).should be_true
table_exists?("customers", @db_name).should be_true
table_exists?("another_table", @db_name).should be_false
end
We have used this technique just a few times and I won’t guarantee it will always be the best option, but so far the result for us is having code that can be executed, demonstrated and easily extended by others, making it easier to transfer knowledge between our team.
