edgecompute.dev

Inventing the Future by Owning It: Reflections on the FutureRuby Conference

Lar Van Der Jagt — Sun, 02 Aug 2009 00:00:00 GMT

I recently attended the FutureRuby conference in Toronto, Ontario CA. It was put on by the incredible people at Unspace & was exactly what I needed at this point in my life.

What is FutureRuby?

FutureRuby is unlike any other conference I’ve heard of. Though targeted at Ruby programmers there were only a few talks which were purely technical in nature. Unspace did a great job explaining their goals in the FutureRuby mission statement:

FutureRuby isn’t a Ruby conference, but a conference for Rubyists. This is a call to order – a congress of the curious characters that drew us to this community in the first place. We have a singular opportunity to express a long-term vision, a future where Ruby drives creativity and prosperity without being dampened by partisan politics.

The distinction between being a Ruby conference & a conference for Rubyists is an important one which was echoed in every aspect of the conference. At a Ruby conference the pivot point is the language itself. What Unspace did was shift that pivot point towards us, the Rubyists.

In his talk Polyglots Unite! Foy Savas provided an excellent definition of a Rubyist:

Rubyist (n): Person who has come to realize, through Ruby, that the computer should serve them and not vice versa.

I wanted illustrate some of the ways Unspace made FutureRuby all about us, the Rubyists. I will discuss some of the standout talks in separate posts.

Telling a Story

There is a difference between an album & a collection of tracks. An album is a cohesive whole where each song supports the others to create a work which is greater than the sum of it’s parts. It tells a story through it’s structure, themes & sometimes words.

Unspace created a living canvas for the speakers & attendees to help write FutureRuby’s story. Over the course of the weekend I took great pleasure in watching this story unfold through the talks, events & conversations. I have no idea if the speakers coordinated their talks, or how much guidance Unspace provided regarding themes, but I was often struck by how each talk seemed to relate to the others in some way.

Themes such as the banality of evil, owning the means of production, personal accountability & introspection were represented. Talks heavy in “wetware” content were spliced with technical presentations & lighter fare, giving us time to consider the implications of previous talks.

The whole thing was capped by a powerful talk from Jesse Hirsch which railed against the Californian Ideology. Jesse urged us to trust those close to us, our friends, families & community over the business interests of the elite. Though controversial, I feel that it perfectly wrapped up several of the recurring themes. I left the conference buzzing with the thrill of new horizons.

Community is King

One of the key points to take away from Jesse’s talk was the importance of community. One of the best things about FutureRuby was the attention put into enabling a community atmosphere.

My first conference was RubyConf in 2008. Being surrounded by so many smart people was inspiring but I didn’t leave feeling like I was part of their community. Unspace created an environment where you couldn’t help but connect with other attendees.

They did this by organizing social events each night. These included FAILCamp on an island, a kickoff party in their offices, a Soviet themed catered gala at the Pravda Vodka bar & a multi-venue block party. Open bars at each event ensured that even the most socially awkward geeks were lubricated enough to connect with our peers.

As a result of these efforts I left the conference knowing that I would miss the people most. I finally felt like a part of this community I’ve been lurking around for over two years.

All in the Details

Throughout all of this Unspace went above & beyond to ensure that the experience was top notch. Extra perks like discounted iPhone training, a workshop where you could grow your own bacteria & transit passes so that you could explore Toronto on your downtime (what downtime?) helped keep us engaged at all times.

The Soviet propaganda theme was consistently used with great effect. Upon registration we were greeted with a canvas swag bag with a FutureRuby patch, pin, book of matches & T-shirt. There was a full sized promotional poster available which I plan to frame & hang proudly on my wall. Even the badges & backdrops for the slides stuck with the iconic Soviet imagery.

The catered lunches & dinner at Pravda were delicious. Food & drink was plentiful & every effort was made to accommodate different dietary requirements.

These details combined with the excellent talks & quality company helped create an experience which was far more than the sum of it’s parts.

Wrapping Up & Thanks

If this reads like a fluff piece, that’s probably because it is. And a well deserved one. FutureRuby ranks near the top of my Best Ever experiences, among multiple European adventures & seeing my favorite band play through sunrise on a boat in the Caribbean. I will do everything in my power to be at any Unspace events in the future.

Some thanks are definitely in order as well:

Pete Forde, Meghann Millard & the rest of the Unspace crew & volunteers for putting their heart & soul into making this the best experience for us possible. Dan Grigsby of Mobile Orchard & Greg Borenstein for going out of their way to make me feel welcome. Joey deVilla for his detailed notes on some of the talks which helped refresh my memory for this post. The Shopify team for keeping the bar open at Pravda. And most importantly all of the amazing people I met for the stimulating conversation & inspiration.

FutureRuby Elsewhere

Unpacking the Tech Debt Metaphor

Lar Van Der Jagt — Mon, 18 Mar 2019 00:00:00 GMT

:::note This post was originally published as a thread on Twitter. I am exhuming it from the ruins of that site as an archive of some of my thinking on the use of tech debt as a metaphor that can be shared in good conscience. It has been lightly edited to fix typos and spelling but otherwise left as is. :::

Gonna do a thread with some thoughts on "technical debt", why I stopped using this metaphor with my clients and the teams I work with, and what I use instead. I've come to believe misuse of the debt metaphor has led to immense hidden costs and harm to software projects.

First, a bit of history about the origin of the metaphor. In 1992 Ward Cunningham wrote an 'experience report' where he describes the idea of technical debt while working on a financial services application: https://c2.com/doc/oopsla92.html

The relevant line from the report: "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite." This matches pretty well with the first cause listed on wikipedia:

Unfortunately, the list goes on for a dozen more items, none of which have much to do with the original definition. This suggests that the metaphor is bearing far too much weight and may not be conveying the message it's meant to.

To understand how this happened, we can take a closer look at the context and process that lead to the metaphor. In order to communicate some risk, Cunningham needed to bridge a gap in understanding about software engineering practices with a stakeholder.

To bridge this gap he reached for a metaphor within the domain of the project, a domain in which the stakeholder was presumably already a subject matter expert in. The debt/interest metaphor was meant to illustrate that a course of action would result in a business liability.

The stakeholder would be in a good position to use that metaphor to ask relatively sophisticated questions about the impact different design decisions might have on that liability. This shared domain context is what gave the metaphor power.

When the community picked up technical debt as a general purpose metaphor that context was lost. It was used to describe almost any case where compromises were made in the interests of expediency. Liabilities were being acquired incidentally without deliberation or awareness.

Taking on real debt doesn't work like this. Terms of repayment are clear. You can calculate the cost of the debt and make business decisions that leverage it to bring you a return. Lenders are (supposed to be) incentivized to ensure your business will be able to repay.

There is a massive industry dedicated to calculating risk to ensure profits can be made. There is a ton of paperwork, legally binding contracts are signed, and there are standard accounting practices to be followed.

When these conditions are not met it becomes more like predatory debt. It's as if you've been funding your project with a steady drip of easy money from loan sharks. They show up to collect at unexpected times and charge arbitrary fees if you're not diligent about payments.

Every decision that results in this kind of debt is like selling a little bit of your company's future out to these loan sharks. This kind of debt can be acquired incidentally and there are no caps so it's easy to pile up.

Every time an engineer gets pinged at 3am to debug that ancient nightly script that nobody can find time to rewrite is a payment. Every feature that gets killed because the refactor needed to support it is too big is a payment.

Every time it takes weeks to onboard a new team member you're making payments on that debt. Every time a developer gets pulled away from feature work to manually patch up some state that got mangled in callback hell you're making payments.

None of these payments end up as a line item on any balance sheet. There is very little institutional awareness that they're being made and it often takes a disaster before anybody realizes the problem. In the worst cases these payments can end up sinking entire companies.

There are also second order effects that can be difficult to account for, such as impact on morale of constantly struggling against technical debt. Poor morale can impact retention and encourage brain drain of those with the institutional memory needed to manage the debt.

There have been lots of attempts to improve this situation by qualifying or classifying different types of technical debt. This can improve the impact of the metaphor but comes at the cost of increased overhead of a larger surface area required for shared understanding.

I took an alternate approach and started to reconsider the debt metaphor itself. I wanted a more intuitive, general purpose metaphor that could apply to the wide variety of situations that get described as technical debt in practice.

I eventually landed on friction. You don't need more than a high school understanding of physics to talk in terms of friction. You can easily come up with scenarios based on friction in a wide variety of domains, and they'll usually be based on far simpler principles than debt.

The technical debt metaphor encourages speculation about the future. The friction metaphor encourages concrete thinking. You can identify existing sources of friction and begin to measure their impacts. You can invest strategically in removing sources of friction.

Most of the "extra" causes of technical debt fit the friction metaphor better. You can talk about causes of the issue, it's impacts and resolutions in terms of the metaphor. You can start to quantify it and make decisions about where to invest to reduce friction.

If your team has been struggling with technical debt it may help to reframe the problem in terms of friction. If you'd like help applying this idea in your organization, I'm currently accepting new clients. Please get in touch!

Temporal Ruby + OpenTelemetry + Honeycomb

Lar Van Der Jagt — Thu, 03 Jul 2025 00:00:00 GMT

A basic example of instrumenting a Temporal Ruby app to send traces to Honeycomb.

Temporal Ruby + OpenTelemetry