Site Downtime

Posted by Nathaniel on Oct 27th, 2006

It figures that right after putting up my RubyConf talk the server I host on would bounce, and I would find out that the cron job I set up to re-spawn the site didn’t quite work. Oh, and that all this would occur whilst I was out all day at meetings. And on top of this, I would attempt to show a client our portfolio page in the midst of a sales meeting and get a 500 error. Oh Murphy, how I love thee, let me count the ways…

Moral of the story? Test your cron jobs, especially the ones that only happen at system boot. Only an idiot wouldn’t (d’oh!).

Open Classes, Open Companies - RubyConf 2006

Posted by Nathaniel on Oct 26th, 2006

This was my talk at RubyConf 2006, and I can’t tell you what an honor it was for me to address RubyConf for the sixth consecutive year. With each passing year I’ve been a little more surprised, since I just know that someday, one of two things is going to happen: either a baby is going to come in October, or the organizers are going to realize they could fill the time better! Until then, though, I’ll just keep enjoying the opportunity to get up in front of some of the smartest, friendliest people I know, throw some ideas out, and learn something from the conversation that ensues. And boy, have I learned a few things in the past six years!

So here’s the basic premise for today’s talk – the language you’ve chosen to spend time with, Ruby, has certain characteristics that in turn reflect back on you, for better or for worse. I want to take what I consider to be some of the most positive characteristics of Ruby and use them to shine a light on what I further consider to be some of the best ways of doing business – at least if you’re a Rubyist.

A disclaimer – we’re going to be talking about my experiences, both personal as well as what I’ve been able to vicariously glean from the writings and presentations of others. I don’t suppose to know very much about business, and in fact, that’s one of the reasons I’m excited to be giving this talk. I’m really, really hoping that you take these ideas about business and turn them over, poke at them, try them out, and report your experiences. That’s what I’ve had the opportunity to do over the last year or so, and what I plan to continue doing in to the foreseeable future, and let me tell you, it’s a lot of fun.

From whence do these experiences grow? Well, at the end of 2005, after trying my hand at being a regular employee (that didn’t really work out), I decided to get serious about doing consulting. Even while making the transition back in to freelance work, it became readily apparent that being completely independent was going to be tough. Either you’re heads down, trying to get client work done, or you’re scrambling to try to find work when you get finished with a client. Sure, you can hold down multiple contracts, but that’s a recipe for not seeing your family much and not having time to work on other ventures.

The other thing I quickly realized when I got back in to consulting was that my 5+ years in the Ruby community was finally starting to pay off, as the Rails boom was driving demand, and I already had an established name. So, I found some of the best developers and designers I knew that were available and interested in breaking in to Ruby and Rails, and I started finding work, sub-contracting it out, and supporting work in progress. Thus Terralien was born – it’s a very different feel from any contracting/consulting company I’ve ever seen (in a good way), and it’s been a blast.

Now that you know a little bit more about where this is coming from, lets jump right in to our analogy. Again, the premise is that the language we’ve decided to spend time with, Ruby, has certain characteristics that we value, and that we can gain some insight in to business by looking at how those characteristics manifest in business. So for our first characteristic, lets look at dynamic. This is one of the first things a lot of people hear about Ruby – “It’s a dynamic language”. It’s good that it’s a positive word, unfortunately it’s also a very vague one. For me, when I say Ruby’s “dynamic”, I’m contrasting that against “static”, and I’m talking about Ruby’s typing. In practical terms, Ruby’s dynamism means that I get to spend my time building my program, not feeding a type checker. The boogy-man of ending up with a type I don’t expect pretty much stays in the closet, and I get a lot more done. Static typing sounds great in theory, but in practice turns out to not be worth the cost.

Where do we find this in business? How about job titles? “Everyone needs to know where they fit and what they’re responsible for.” Sounds good in theory, but does it work out so well in practice? Think about your current title. Does it help you do your job? My experience has been that when you stick a person in a box, they happily stay in it. This is nice for Human Resources, since it makes it easier to figure out what to pay that person. It’s not so nice for the long-term success of your business, however, since that person becomes, even if just sub-consciously, limited in what they will and won’t do by the title they’ve been given.

In Ruby we have duck-typing, right? If it walks like a duck and quacks like a duck, it must be a duck. When I came to RubyConf in 2001, I was a programmer. I bet you can list off a litany of things a programmer is – but have you ever thought of what a programmer isn’t? A programmer isn’t an accountant, isn’t a “business person”, isn’t a salesman, isn’t ultimately responsible for the success of the business. And so when I came to the 2002 RubyConf in Seattle, I wasn’t a salesman, even though I’ve now found out that I can quack a lot like a salesman. What if I hadn’t been boxed in by my own myopic views of titles? Maybe I wouldn’t have been laid off in 2003, because maybe I would’ve grown beyond the code and taken ahold of the business.

Of course, hindsight is 20/20, and I’m sure there was a lot I needed to learn between where I was then and where I am now – things that help me to sell now. Things like Ruby, which has since taught me the power of dynamism and not being too quick to label things.

Where to next? How about this one – Ruby is interpreted. By this I’m not so much referring to Ruby’s current implementation that happens to run the program straight out of source code, but rather to the fact that in Ruby, the program that gets run is order-dependent. I know coming from Java to Ruby, this one tripped me up – the difference here goes way beyond not having a “main” method. Once you embrace the simple fact that Ruby strictly, without fail, interprets statements as it encounters them, you’ll start to understand something fundamentally different about Ruby, something that adds great power. For instance, all that nifty meta-programming in Rails that gives us validates_presence_of and it’s ilk – that flows from the interpreted nature of Ruby as much as it does from the ease of meta-programming.

So what insight for business can we draw from Ruby’s interpreted nature? How about this – it’s much more powerful to be able to react to changes as they happen than it is to plan what’s going to happen in advance. Interpretive code is inherently more flexible, because so many things can be decided at run-time, and in the same way, a business that can put as many decisions off until the last possible moment is a business that will weather external change much more smoothly. Of course, Ruby’s built for this, and a business that’s going to do it will have to be, too.

Have you read the original Jurassic Park? One of my favorite parts of that book is the meta-narrative that surrounds the chapters, which weave a lecture by the book’s mathematician character around the whole “modern day dinosaurs” theme. In that meta-narrative, he explains how systems must walk the line between order and chaos. If they get too ordered, they will become too rigid, and get overrun by something more flexible. If on the other hand they become to chaotic, they will lose cohesion and fly apart at the seams. When I talk about putting decisions off, I don’t mean to imply that decisions should be avoided altogether – rather that we want to remain adaptive until the last possible moment, make a decision when we need to and then keep moving. This line between chaos and order is fine, and I think Ruby walks it well – hopefully my business can do the same.

Paul Graham is entirely too quotable – that guy just needs to slow down and let the rest of us catch up. Anyhow, he has this great quote, actually the title of one of his essays, “Succinctness is Power”. To me that sums up a lot of the reasons I think we’ve seen Ruby catapulted from obscure language out of Japan in to “blow the doors off of RubyConf” popularity. Ruby is succinct, and I believe from what I’ve heard matz say both just last week on ruby-core and at RubyConfs in years past that succinctness is one of his goals for Ruby.

What’s so great about succinctness? Well, it allows us to do more. The hypothesis Paul Graham puts forward in his article, and that I’ve found holds true in my own experience, is that the amount of code we can produce is somewhat constant, on average, regardless of what language we’re using. If that’s true, then the more functionality a language allows you to implement in the same amount of code, the more powerful that language is. Of course, someone who uses PERL could stand up now and assert that PERL must therefore be more powerful than Ruby, because I think we can all agree that PERL is often more “succinct” than Ruby. The problem is that succinctness is a read/write thing – code is read more than it’s written, and for succinctness to be powerful, it can’t be in a funky shorthand even the author has trouble reading afterwards.

So Ruby is power, I’m preaching to the choir, ra, ra, etc. What about business? Well, let me tell you one of the things that I think has been a secret of my success with Terralien. It’s a closely guarded trade secret, you know… well not really. Actually it’s just that I’ve never asked a client to sign any agreement of any kind longer than two pages in length. And the second page is usually just signatures. What’s the secret here? Well, if succinctness is power in programming because it makes better use of the limited amount of code we can generate in a given week, then a succinct legal agreement is power because it makes wise use of the limited attention a client can give to figuring out what in the world he’s signing his name to.

Big disclaimer – I am not a lawyer, and you should talk to one before you take my advice here. However, I would also encourage you to find a lawyer you can have a good fight with, because too much legal advice is just taken at face value. Have you ever had the feeling that you’re just sort of making things up as you go along, and you wonder when somebody’s going to figure it out and call you on it? Well, your lawyer does that to. Sure, he’s had some expensive schooling, has some experience, and I’m sure he knows more about the law than you do, but he’s in a box (remember those?). From that box, everything is a threat except the fact that you might never actually do any work if you spend all your time worrying about threats.

Here’s the key point – legal agreements have one purpose, and that purpose is to properly set expectations on paper, so that nobody gets surprised. When succinctness is neglected, we end up with a situation where that purpose is lost, and the legal document can actually obfuscate the expectations of each side, with each side defending their position rather than trying to come to a common understanding so they can work together.

Lets say you’re an employee – how does this apply to you? Do you understand your employment agreement? Does it succinctly state both your and your employers expectations? Or does it obfuscate the fact that they expect you to be a corporate slave (maybe they call that the “no moonlighting” clause)? Or perhaps it says they want you having no part in that “open source” thing? I would highly recommend having a look at what you’ve agreed to, and making sure your expectations are in line with your employer’s.

The next Ruby quality I’d like to consider is reflection. Now, a lot of languages have reflection, but what I find great about Ruby’s reflection is its extreme transparency and the way it’s built in to the language from the ground up. Rather than an occasional trick used to work around language limitations, reflection in Ruby is a constant companion. One reason I think reflection is so key to Ruby is Ruby’s dynamic nature we talked about earlier – we have to have reflection in order to deal with everything not having a label.

In business, I think the same is true. If we don’t box ourselves in with titles and roles, then we need constant reflection on what we’re doing, how it’s working, and what we could change. Ask yourself – does the business you’re involved with now make asking questions about the way things are done easy? Or is it uncomfortable and potentially perilous?

The last characteristic of Ruby I’d like to discuss is the first one I analogized when I was trying to write a proposal for this talk. It’s also potentially the most controversial out of the bunch. I’m talking about Ruby’s open classes – allowing any code, anywhere in the program, to open up an existing class and add functionality to it, remove functionality from it, or generally mess around with its internals. Of course, this goes so far as having “evil” methods like #instance_variable_get and #instance_variable_set that allow us to intentionally break encapsulation. Could I break things horribly? Sure, but Ruby treats me like an adult and for that I love it.

Here’s the trade-off I think Ruby makes in intentionally allowing open classes – it values open communication and implementor power over security through obscurity and implementor safety. That’s something I want to do in my business – trade the security and safety of hiding information for the possibility of my sub-contractors and clients suggesting and doing useful things I never would have thought of because they can see what’s going on inside my business.

This can get scary, because when people close to you know so much about you, they can really hurt you. However, I’ve found that open communication, especially in the face of personal risk, is very good at building trust, which is the essential ingredient of any successful business transaction. If you don’t trust the other person, I don’t care how great your lawyers are, the deal is not going to be a good one in the long-term.

How does open communication work in practice? Well, do you know what your peers are paid? Do you know what deals are in the pipeline? Can you see the books any time you want? Have you been offered stock options where the big guessing game is, “how many outstanding shares are there?”

The real kick-off for Terralien was engendered by Campfire’s lacking access controls – I wanted to invite a bunch of the best developers I knew in to my Campfire, but I also wanted to be able to discuss confidential client information without worrying about who was listening in. So I created a one-page agreement that basically said, “You’ll keep client information private”, and sent it around. What it didn’t do was place any restriction on sharing Terralien internals. Could someone use something they learn to hurt me? Probably. Will they? I don’t think so because I trust them.

One more example – I send out Statements of Work to my sub-contractors via Basecamp as private messages. The first time I had two subs on a project, I realized that they would be able to see one another’s hourly rate, and in this case, it happened to be different. I did it anyhow, though – if I can’t explain the rate disparity to them, why does it exist?

So, am I naive? Probably. But I think Ruby’s open classes are wonderfully naive as well.

So, five questions to ask yourself about your current situation:

  1. Are you boxed in by a title?
  2. How much is planned ahead, and how much remains flexible and gets dealt with as it arises?
  3. Do you understand the agreements you sign and/or give others to sign?
  4. Is introspection rewarded or penalized?
  5. What’s the default for information? Allow or deny?

I’m assuming that to some extent, if you value Ruby, you value things that are dynamic, interpreted, succinct, reflective and open. If so, and you’re not in a business that also values those things, why not?

Terralien In Lights!

Posted by Nathaniel on Oct 2nd, 2006

I just couldn’t resist:

Via RedHanded.

You can still contact Nathaniel at