Comment on RubyConf: Nathaniel Talbott: Open Classes, Open Companies by Platte Daddy

2006-10-25T04:42:12+00:00

Commenter x, the same argument can work the other way: if you find static typing indispensable, your systems probably have other problems.

Amazon writes big enough programs, I imagine we could agree, and have become a completely service-oriented shop, each feature running separately from the others, in whatever language suits. Imagine all the work they don’t have to do to make changes to those systems.

Comment on RubyConf: Nathaniel Talbott: Open Classes, Open Companies by x

2006-10-23T16:56:58+00:00

If you don’t find static typing useful, you don’t write big enough programs.

Take a look here for a contrasting view on the dangers of duck typing:

http://beust.com/weblog/archives/000269.html

RubyConf: Nathaniel Talbott: Open Classes, Open Companies

2006-10-21T18:54:00+00:00

Update: Full text of Nathaniel’s talk.

Nathaniel is honored to be speaking at RubyConf for the sixth year in a row. His basic premise for today is this: the language you’ve chosen has certain characteristics that reflect back on you. In turn we can reflect on those characteristics and how they relate to what we value in business as well.

Dynamism

Ruby’s typing system (contrast to static typing). I’m thinking about my program, not satisfying the type checker. Static typing sounds good in theory but I haven’t found it that helpful in practice.

How about dynamism in business? How about job titles. If you stick a person in a “box”, they pretty much stay in it. It’s easy for HR, but not good for the growth of the business. In Ruby we have duck-typing, but a fixed job title is kind of like static typing. It makes it harder for you to adapt to the situation at hand, or keeps you from growing into new roles you never thought you could do. Nathaniel mentions how he, as a programmer, never thought he could be good at sales, but now he likes it.

Interpretation

The behavior of the program is order-dependent (contextual). Once you embrace that Ruby interprets statements as it encounters them, you find power in it. It allows you to delay decisions until they’re necessary, a feature that supports dynamic business.

Succinctness

A stated design goal for ruby (by Matz) is succinctness, but not just brevity for brevity’s sake (e.g., extremely compact Perl), but in a read/write sense.

A succinct legal agreement is wise use of the limited time a client has to figure out what he’s signing up for. Legal agreements should have one purpose -- to set expectations so that no one is surprised.

Maybe your employment agreement is so long and full of legalese that you’ve inadvertently signed up as a corporate slave. Be wary; ask for a summary; consider how it might affect your ability to contribute to open source projects.

Reflection

Ruby the language permits and even encourages a high degree of introspection. Does your workplace reward introspection, or penalize it? Or is it a “fire and forget” environment?

Open classes

Ruby allows any code to open any class, add/remove code, muck with state. Could we break things everywhere? Yes. But Ruby values implementor power over safety or security through obscurity. This can be scary for some.

When people close to you know a lot about you, they can hurt you. You’re vulnerable. But the other side of this is that being open builds trust, which is an essential component of a successful business relationship.

Do you know what your peers are paid? Do you know what deals are in the pipeline? Can you look at the books?

Ruby’s open nature may seem naive, but it’s wonderfully naive.

Discussion

Q. Would these techniques work outside of a technical hub? My business is not driven by locale. I’m able to assign work in a distributed manner.

Q. You assume that your peers are trustworthy and honest. What about in a more cutthroat competitive environment? You either need to change your organization or “change your organization”, i.e., switch jobs or try to effect change to find a place that reflects your values.

Q. Transparency meets the real world. Crashing software and crashing companies are two different things -- perhaps the analogy can only be taken so far? The worst that could happen is that I get nothing for the time I invest other than the learning experience. It’s more a matter of limiting risk. I’m not saying I’m broadcasting every detail to every client.

Q. Do you scope clearly and bid, or do you do ongoing hourly work? I only do time and materials. RFPs make me gag. People spend time on the piece of paper and then give it more credence than my own opinion.

Q. How does testing play into this? One thing that Ruby values is constant feedback, which is also a big tenet of testing. Constant and short feedback cycles, “testing your customer” -- don’t get caught in a long-term agreement.

Q. How do you put that in a statement of work? I make sure the client knows that we’re building a trusting relationship. I also don’t claim to have this all figured out.

Q. Can you scale this (team of trustworthy people) to a larger model? This is in a way like the evergreen question about Ruby; “does it scale?” Partly, I don’t care because it’s working for me now. On the other hand, I’m thinking about it because I like the thought of bringing more people into the fold. [A comment from the audience brought up the subject of lifestyle companies as an example of why it wouldn’t.]

Q. There are two types of contracts -- the 2-page business agreements and the 50-page CYA edge cases. True, I have the luxury of working with clients that small enough that they are not likely to sue me.

Q. If everyone is a sub-contractor, there is no career path or “carrot”. Part of the goal of my business is to catapult people beyond it by allowing them enough free time to work on their own things.

Q. How do you balance work and life? I’m not always the best at it, but now I’m working out of my house and can be with my family when things come up. Some days I shut the door and get things done. Work/life balance is messy and I work on it on a daily basis.

Nick Sieger: RubyConf: Nathaniel Talbott: Open Classes, Open Companies