One of the big problems of today is working with live code. Now a team at Github has a very clever tool that makes it easy to make, and evaluate, changes in live code in the same way that you might replace a bridge.

The idea is that if you were going to replace a bridge you wouldn't knock it down and build the new one, you would build the new one alongside the old and only switch to using the new bridge when it was proven. 

This isn't quite the idea behind Scientist - a Ruby library for carefully refactoring critical paths - but it is the general motivation. It is also related to an older, and not so well known, idea: BranchByAbstraction. This is a software development pattern that facilitates refactoring by gradual replacement of one module by another. Again the similarity isn't perfect and in many ways Scientist is a more pragmatic implementation of the idea of replacing one module by another in a controlled way. 

The library is written in Ruby because much of GitHub's infrastructure is Ruby-based and it is intended to allow its refactoring and upgrading.

Using the library is "cute" in terms of its jargon - all based around science. Suppose you have an alternative implementation of a method that you are trying to phase in. You can do it using code something like:

require "scientist"
class MyClass
  def method(data)
    experiment = Scientist::Default.new "myExperiement"
    experiment.use { method1(data) } # old way
    experiment.try { method2(data } # new way

    experiment.run
  end
end

The key idea is that you wrap a "use" around the original behavior and a "try" around the new behavior. In the "sciency" jargon the use is called the control and the try is called the candidate.

The result of the experiment is always what the use block returns, but the try block is also executed. The experiment.run method does a lot of things behind the scene: 

• It decides whether or not to run the try block,
• Randomizes the order in which use and try blocks are run,
• Measures the durations of all behaviors,
• Compares the result of try to the result of use,
• Swallows (but records) any exceptions raised in the try block, 
• Publishes all this information

There is a lot more to learn. You can specify what the results are using the context method and a hash defining the data. You can also publish the results by implementing the publish(result) method and process the data in any way you care to. Once you are happy that the experiment works you can simply take down the scaffolding and start using the new code. 

You can see a slightly out of date account of how the system was constructed and used in the video below:

There are lots of problems of course and this isn't a complete cure. If the new code has any side effects, like writing to a database or changing the state of the system in any way, then running old and new in parallel is not so safe. 

What is important about Scientist is that it might make other programmers think about how this sort of thing could be done. Perhaps we can make it more like building a parallel bridge before knocking down the old one. 

More Information

https://github.com/github/scientist

Clever New GitHub Tool Lets Coders Build Software Like Bridges

Related Articles

Does Syntax Coloring Work?

Debugging and the Experimental Method 

DARPA Funds Big Code Database Project

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on, Twitter, Facebook, Google+ or Linkedin. 

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info