Adam Savage posted a marvelous video of his attempt to build a giant brass nut and bolt. It reminds me of software.

The video is about 35 minutes long, and in my opinion it is a “must watch” for my readers. Adam Savage’s One Day Builds: Giant Nut and Bolt!. Before you dig in, let me mention a few things to watch for. Here’s the blurb from YouTube:

Adam expands his machining skills in today’s One Day Build by attempting to machine a giant bolt and nut out of a chunk of brass. It’s a thorough test of Adam’s abilities working with his lathe and precision machining, as the two comically large parts have to fit in the end!

In this video, Adam tells us that he’s working in an area where his skills are low, specifically in making threaded objects. He’s also working on the largest piece of brass that he can remember working with. Watch as he needs to adjust his tools and techniques to deal with it.

In software, we often need to adjust our tools and techniques.

He speaks of how difficult it is to assess someone from their portfolio of work, because as nice as a piece may be, he can’t assess what they set out to do, so he can’t assess how close they got to their objective.

In software, we rarely, if ever, finish up with precisely what we set out to do.

He gets into trouble as he goes. A couple of times he describes the cause as “getting greedy”, trying to move too fast, to do too much in one pass.

In software, we invariably do worse when we try to move too fast.

He’s visibly unhappy at some points in the video, and freely admits it. You can see him pause to try to settle his feelings. (I have thrown things across the room at points like this.)

In software, our failures often make us unhappy or angry, and we need to deal with it well.

His estimate of how long this project would take was off by a factor of at least two. It was supposed to be a “one day build” and it took two! This was a simple nut and bolt. How could he hold up his head when he is such a poor estimator? We know better, don’t we? We can’t see the difficulties going on. Estimation is a dark art, especially when it involves the future.

In software, we are often required to estimate, and it’s almost always a problem.

In the end, he winds up with a very nice result, which he has polished to a mirror shine. It’s a piece he was proud to make and certainly I’d be proud to do something that nice.

In software, we can often wind up with polished results as well. Sometimes … not.

Adam makes the point multiple times that the way we learn is by making mistakes.

In software, we have a chance to learn a lot, because we sure make lots of mistakes.

Now please go watch the video, in its entirety, and then come back and read what follows.

Or don’t. I’m not the boss of you.

Hi, welcome back.

In software, we often need to adjust our tools and techniques.

Since I’ve been programming for well over half a century, I’ve used and become expert over a very wide range of languages and tools. And, since I haven’t used most of them for a good fraction of a half a century, my skill with most of those has fallen off quite a bit. Even worse, there are tools and languages with which I have little or no experience, and if I were working for a living, odds are I’d have to use some of them.

Remember that scene where Adam sets up his auto-advance tool with what looks like twenty knobs, dials and handles? That’s how I feel the first time I’m faced with a new tool. It’s possible to become expert … and it will take a while. Between beginning and ending, I’ll make a lot of mistakes.

In software, we rarely, if ever, finish up with precisely what we set out to do.

Adam finishes with a beautiful piece … except that because of mistakes, he had to machine the bolt head smaller than intended. He didn’t machine the nut down to the same size, although he certainly could have. He doesn’t say why he did that. One possibility is that this “one day build” had already taken two days, and he wanted to stop. He was out of time.

Another possibility relates to his initial remarks about a portfolio of work and allowing the viewer to see the difference between the goal and the result. Had he machined the nut down to bolt size, it would have hidden the error that made machining the bolt down necessary. Comparing the two pieces, we can see the reality of the mistakes, and we can see how well the final result turned out nonetheless.

My guess is that he thought of both these notions, and that being out of time was the larger motivator. In our software, “out of time” is almost always what makes us stop.

In software, we invariably do worse when we try to move too fast.

At least two different times in that video, Adam says that he encountered a problem because he got “greedy”. One way of looking at most of my mistakes is that I got too greedy. I tried to go too fast, to take too big a bite, to proceed without a test, or without at least a hand calculation to see what result I should get.

And often, when that happens, things go badly. In Adam’s video, there’s a moment of truth when he first tries to put the nut on the bolt. If anything has gone wrong, the two threads will not match and it’s game over. Here we have an advantage over Adam. If that had happened to him, he’d have had to remake at least one of the pieces. We can usually replace an interface and leave things as good as new. Software is soft; even softer than brass.

In software, our failures often make us unhappy or angry, and we need to deal with it well.

If you’ve never felt angry or frustrated during programming, either today is your first day, or you haven’t been paying attention. (I suppose there’s some chance that you’re perfect, but I’ve met at least a dozen programmers already, so my guess is you’re not.)

To me, software is one of the very few things that I flatter myself that I’m good at, and when things go wrong, that’s a direct challenge to my skill. If I’m doing something entirely new, maybe I can comfort myself with the fact that I’m just learning, as Adam does in his video. He’s also visibly frustrated anyway. Somehow in his heart he feels that he should know better and do better than he did, even though he’s been building things and recovering from mistakes for decades.

We feel that way too. It’s OK. It’s a property of creating things.

In software, we are often required to estimate, and it’s almost always a problem.

You can read my remarks on estimation, but one way or another, we’re often required to estimate, or at least to hit some seemingly arbitrary date. Often, we run over. I would “estimate” that every project I’ve ever been on has run over its estimate or deadline, and despite that, I’ve had some successes. (I’ve also lost jobs and positions, so listen up on this next bit.)

We can build software incrementally. For any even remotely sensible deadline, and for most of the rest, we can build the product such that it is always ready to use, ready to be shipped, save only that it lacks some features – and those features are the least valuable ones remaining to be done. We can build, feature by feature, most valuable first, and integrate the product. We can even do that within a feature, building the most important aspects of that feature, and leaving the polishing and frills for later.

By doing that, we can have a product ready to go almost from the first day, and that can be a great advantage to ourselves, to the team, and to the company.

Could Adam have built some kind of simple fastener that would “work” and evolved it into his lovely nut and bolt? I truly don’t see how. We have the advantage. We can do software in any order.

In software, we can often wind up with polished results as well. Sometimes … not.

Adam did the polishing at the end. 400 grit, 1000 grit, zillion grit. The thing shines like a mirror. (It also takes fingerprints like a mirror.) We rarely get the chance to do that polishing in our work, and in fact trying to do too much polishing is risky, because unless all the essentials are done, we should focus on essentials.

Adam was making a display piece, a literally beautiful construction of brass. I would be proud to own it and put it on my shelf, right near my Berrocal Goliath and my cast saber-toothed cat skull. In software, we’re not usually making display pieces, and we need to be careful where we polish. Our user interface probably needs to be squeaky clean. The API to our memory management routines … not so much.

In software, we have a chance to learn a lot, because we sure make lots of mistakes.

What I loved about this video was that Adam knew he had things to learn, he knew his skills weren’t at peak, and he was using what he knew to edge those skills forward with this piece. And he still got greedy and he still make mistakes. And he was wise enough not to blame his machines, even when one of his tools broke. He knew that the responsibility for making this thing lay with him, and he owned the mistakes.

And best of all, we could see that he felt badly about the mistakes, because he felt they could have been avoided, while all the time realizing that because he was new to aspects of this work, mistakes were inevitable.

We learn from mistakes. This video was a delight to me, because it felt exactly like I feel when writing software.

My thanks to Adam for one of my favorites from his series, and to all of you for reading. Comments welcome on Twitter.