Programming Clojure – classpath for Emacs and Slime

This is probably obvious to a lot of people, but I had a hard time trying to figure out how to get emacs/slime to see my clojure and java stuff. I was able to get it all up and running when I started Clojure from the command line, but when using slime, it was unable to locate all the extra stuff I wanted it to. After a bit of googling, I found out how to do it. Put the following line before calling (require ‘swank-clojure-autoload) in your dot emacs:

(setq swank-clojure-extra-classpaths (list "/class/path/1" "/class/path/2" "/class/path/3" "etc"))

Restart emacs, start slime, and it will now find everything on those paths 🙂

Software development agility – bottom-up design and domain-specific languages (DSLs)

It’s been nearly three months that I’ve been working at Runa. And in that time I’ve worked with the team to get a lean and agile process in place, and while we’re not there yet, things are getting more and more focused every day.

I’ve also been working to significantly re-factor the code that existed, as we get ready to get the first beta release out the door. In this post, I’d like to talk about one aspect of our design philosophy which I’m glad to say has been working out really well – bottom-up design (and an associated DSL).

Before we decided to change the system, it had been designed in the usual top-down manner. Runa operates in the online retail space – we provide web-based services to online merchants, and while we have a grand vision for where we want our platform to go, our first offering is a promotions service. It allows merchants to run campaigns based on a variety of criteria. Merchants are a fussy lot, and they like to control every aspect of campaigns – they want to be able to tweak all kinds of things about it.

In true agile fashion, our initial release allows them to select only a few parameters. Our system, however, needs to be extensible, so that as we learn more about what our merchants need, we can implement these things and give it to them. Quickly. And all of this needs to be done in a changing environment with lots of back-and-forth between the business team and the dev team.

So here’s what we came up with – it is an example of what we call a campaign template –

campaign_template :recapture_campaign do
  title is 'Recapture'
  subtitle is 'Reduce cart abandonment rate'
  description is 'This campaign presents offers to shoppers as they abandon their shopping cart.'

  #adding criteria here
  accept required time_period_criteria with defaults start_date('1/1/08'), end_date('12/31/10')
  accept required product_criteria with no defaults

  hardcode visit_count_criteria with number('1')

  #more criteria
  reject optional url_referrer_criteria with no defaults

  inside context :view_badge do
    never applicable
  end

  inside context :abandon_cart do
    allow only customer_type_criteria with customer_type('visitor')
  end

  inside context :cart do
    allow only user_action_criteria with user_action('accepted_recapture')
  end

end

A campaign template behaves like a blue-print of an actual campaign. Sort of like the relationship between a class and an object. In a sense, this is a higher-order description of just such a relationship. The (computer) language now lets us speak in the domain of the business.

There are a couple of reasons why our core business logic is written like this –

a) It lets us communicate easily with the business. Whenever a question about a rule comes up, I bring up the associated template up on the screen, and make them read the ‘code’. Once they agree thats what they mean, it just works, because it is real code.

b) Since this is in essence a way to script the domain model, it has forced a certain design upon it. All the objects evolved in a bottom-up manner, and each does a very specific thing. It lends to a very highly de-coupled design where objects collaborate together to achieve the higher goal, but each is very independent of the other.

c) This notation makes several things easier. One, the actual business rules are described here, and they just work. The other thing is that we’re able to use this same representation for other things – for example, our merchant GUI is completely auto-generated off these template files. Menu items, navigation, saving, editing, error-reporting, everything is generated.

This allows very fast turn around time for implementing new concepts, or making changes to existing ones.

It’s an internal DSL written in Ruby, and does whatever it can without any extra parsing, as you can probably imagine. I will write about the specifics of how this is implemented in future posts. For the moment, I would like to stress, however, the importance of the bottom-up approach. Because our domain model is made up of many small objects (instead of a few larger ones), each representing a tiny aspect of the domain, we’re able to put them together and fashion more complex beasts out of them. And the combinations are limitless, bounded only by business rules. This is where the power of this approach lies.

The DSL itself is almost only a convenience!

What iteration-less agile really means

I’ve written about the idea of an iteration-less process before, and we’ve been using the spirit of the idea at the startup I work at (Cinch) for the past few weeks.

The idea is simple, and has two parts. First, eliminate the concept of formal iterations (use a pull-system to let work flow through the pipeline – use Kanban cards if you like). Second, replace the rhythmic heart-beat of iterations with actual releases to customers (internal or external).

These releases do not have to be spaced out by a week or two or any arbitrary span of time. They ought to be, in fact, the shortest amount of time that the software system can be re-stabilized after undergoing change (through adding features or fixing defects). Hence, if it takes 2 days to do a release, do it then. If, for some reason, it takes 6 days (instead of the old five), then so be it. However, the focus of the team should be on getting quality software into the hands of the final users. After all, everything else is inventory.

Pretty simple, eh? We have combined this with the idea of the estimation-less process, for even greater effect. I have been hearing from some people that I have worked with in the past, and they’ve reported excellent results through just such a process. So, anyway – that’s what iteration-less means. 🙂

P.S.

In a past life I had spoken about this with Jeff Sutherland when I attended Deep Lean (in 2007) – and he agreed that this made sense. He didn’t recommend it for any but the most experienced team – and I certainly agree with that. If your team is new to agile or is lacking in some other way, getting it going with the standard approach to agile is probably the best thing to do.

However – if your team can pull this off, you might want to give it a shot and see how much productivity increases over time.