Noel Rappin Writes Here

This is the weekly newsletter for the Tech Done Right podcast. If you like this newsletter or have other comments, email me at techdoneright@tablexi.com. And tell your friends to subscribe at http://techdoneright.io/newsletter.

Five Things Give Or Take Two

RIP DBC

The big news in my little corner of the world is the closing of Dev Bootcamp. Many of the original Chicago DBC staff were former coworkers of mine. Here’s Dave Hoover’s photo set from the first couple of years. I have some complicated feelings about the bootcamp movement, which I’m hoping to get to on a future podcast episode (here’s an interesting Twitter thread from Sarah Mei on the topic). But I will say that I’ve interviewed dozens of Chicago DBC graduates over the last five years, and almost to a person they are smart, eager to learn, and extremely aware of the idea that they are at the beginning of the their knowledge journey. Thanks to the DBC staff for their time and commitments, and to the students for all that they have brought to our community.

Ruby Friday

From the “yep, it’s 2017” file, we present two articles on topics that it seems like Ruby has been debating for a decade or more.

First, Nate Berkopec arguing that Ruby is not too slow for big websites. Which is true, but I can not believe we are still having this conversation. I believe the following things here:

• Ruby is slower than other languages.
• There’s a real good chance that Rails is not your performance bottleneck in production (which is basically the argument Nick is making).
• The number of business that actually fail because they can’t get to web scale is minimal compared to the number of business that fail because they can’t get the code working in the first place. Or, to quote DHH “Programmers worrying about whether their architecture will Web Scale is like buying a lottery coupon and fretting about which yacht to buy.”

In other words, make the site work. You’ll have to change the architecture when you get to web scale anyway…

If you prefer to argue that Ruby is just too dynamic to do real programming in, here’s Max Jacobson to show you there are no rules in Ruby. Max shows all the ways you can deviously trigger a runtime error in a seemingly innocuous bit of Ruby code. (To be clear, Max isn’t saying that Ruby is bad, he’s just pointing out how flexible it is.)

At the first Ruby community event I ever attended, literally ten years ago next month, Dave Thomas, then of Pragmatic, gave a talk about Ruby metaprogramming where he said that if your team is misusing Ruby’s flexibility, “that’s not a technology problem, that’s a people problem”, and then sarcastically recommended a more violent solution than most HR departments would condone.

Don’t talk back

Yak Shaving is one of my favorite developer slang terms. It’s so evocative. This week, Jessica Kerr posted a taxonomy of Yak Shaving, the main point of which is that different yaks need to be shaved for different reasons, and provide different benefits. Sometimes the benefit is just that you can do your work at all, and sometimes, the benefit is that you can improve your workflow and do things faster in the future.

Okay, Look

Wiffle Ball? Sure, why not. Narratively’s C. Brian Smith presents a story about professional Wiffle Ball. As in the backyard game with a plastic bat and the plastic ball with the asymmetric holes. All I’ll say here is that this video, which is largely pitchers making waffle balls curve in ways that defy the laws of physics as I understand them, is oddly mesmerizing.

In a related story, here’s an episode of the Start Up podcast about Slamball, which is basically basketball on trampolines. You may Slamball remember from cable TV a few years back, and it is apparently poised for huge growth in China, which honestly feels a lot like a William Gibson novel.

On The Podcast

This week on the podcast, we have Doc Norton and Table XI’s Claire Podulka talking about Doc’s book Escape Velocity (and to a lesser extent my book (Trust-Driven Development). The question is how do you measure the success of an agile team? The traditional answer, “velocity”, is maybe unhelpful. This was a great chance for all of us to jump up and down about faux-agile practices we hate. Some quotes:

DOC: The reality of it is for a high-functioning agile team, Velocity is a helpful metric but for a team that is getting started, because there are so many different problems in the system, velocity is highly variable or it’s just unreliable and it’s actually creating, I think, bad behaviors for these teams. … The thing is the work you need to do and the things that you measure to get to the point where velocity is a useful metric, basically obviates the need for velocity at all because you can continue to use those metrics.

DOC: When it’s the only measure that we have, we start to see interesting behaviors around anything from, maybe we’ve got to set a target for Velocity. We believe that there’s, let’s say a thousand points worth of work left and we’re doing on average 20 points per iteration but we don’t have two years to do this so we need the team to get to 25 points. The moment that we actually set a target for a metric like that, unfortunately what it does is it incentivizes the team to change their behavior so anything from, maybe they actually do move faster but quality goes down and we’re not measuring quality so we don’t notice that.

NOEL: I’ve always thought that one of the problems with the whole ‘you should estimate better’ kind of thing is an unwillingness to accept the idea that estimates are estimates and not written in stone, ‘I’ve seen the future in this story is going to take me two days.’

CLAIRE: I think one of the problems you start to run into there when you start playing with…”We’re going to hit 25 points next iteration because we have to.” It really negates a lot of the benefit of agile entirely because agile is all about let’s deal with reality and be really upfront and honest about this situation of what we can do and monkeying with the measures of things isn’t actually dealing with the reality.

As usual, that’s just from the first few minutes, there’s a lot more goodness in the entire show.

One More Thing…

Justin Searls casually dropped the phrase “post-agile” in a tweet this week, and I’ve been thinking about what that word might mean. I haven’t fully thought the idea through. I think Agile is, as Claire said, a technique for dealing with reality. And I think the Agile and XP practices are often about taking things that are hard and doing them continuously, in smaller steps, to make them easier. So I start to think about what has become hard or become easier because of the way developer tools have evolved in the last ten or fifteen years.

I think that continuous, real-time, collaboration tools like Slack, are clearly post-agile, both for good, and for bad. “On-Site Customer” was an original XP practice, and Slack-like tools make customer access much less logistically complicated. Similarly, on many teams Slack has replaced or largely replaced daily stand-ups. Again, I’m not sure this is completely a good thing given current tools or current practices, but the potential for useful continuous collaboration is there. Somewhat related, there’s always been a tensions between Agile/XP and remote work, which I also think that Slack-like tools help with.

The original XP practice of continuous integration seems so modest compared to the way my teams use GitHub, or continuous deploy, or might use something like Docker for basically continuous access to production architecture. Continuous deploy definitely feels in the spirit of the original.

I’m still thinking this through.

See you next week,

Noel