75   mokacoding.com

What can a pipe wrench teach us about software engineering?

36 comments

 by ingve

Refreshing Comments...

An interesting thought experiment would be to give the description of the pipe wrench to engineers without telling the what it was or what it was used for. Then ask them to design a tool that matches that description.

Probably much like with software designed from a description, there would be multiple solutions, all of which would meet the requirements given. Some would be better than others, some worse. Some would share common engineering designs, others would be completely unique.

And in the end if someone created a functional and usable tool for the job required (rotate pipes), who is to call those that don't accurately recreate the original wrong in their solution?

I realize by the way that the article is more about precision code like that description rather than writing code from the precision description. But still, there is still the concept that even precise things are open for interpretation.

[-]
From the article: By turning the nut to the right or left the movable jaw may be moved either toward or away from the fixed jaw, as may be desirable. The inner face of the movable jaw is formed at a right angle to its shank, and is also provided with a series of teeth, which pitch or rake on its fellow jaw...

This misses the key feature of a pipe wrench. The movable jaw has some swing such that it will tightly hold the pipe when moved in one direction, but will release the pipe when moved in the other direction. This provides the equivalent of a ratchet.

This is what distinguishes a pipe wrench from an ordinary adjustable wrench. It's that small amount of swing motion that gives it the ability to grab round things tightly. There are other forms of pipe wrenches which have a chain or a strap[1]. They do not have a jaw adjustment nut but do have the ability to grab round things and a grab/release ratchet-like action.

The actual patent language (Stillson, 1869): "The lower part of the frame c extends forward of the shank A, and is recessed out, so as to permit said lower part to swing to the rear a sufficient distance only to bring said jaws nearly or quite parallel with each other." There's the swing part. Note another key part of the invention. The jaws won't close beyond parallel, so if you pull hard on the wrench, you rotate the pipe but don't crush it.

In the original patent, we see the "why", as well as the "what". The novelty of the invention is in the "why". This matters. If you made the tool described in the article, you'd have an adjustable wrench with teeth that would slip when you tried to tighten a pipe.

[1] https://www.homedepot.com/p/Crescent-12-in-Chain-Wrench-CW12...

Ironically, the quoted description of a pipe wrench seems to be from a patent [1] that's full of references to a picture.

And it seems doubly strange to choose a patent as an example of precisely and uniquely describing an invention in the modern age, when patents are written as broadly and imprecisely as possible.

[1] https://patents.google.com/patent/US126161A/en

[-]
Yeah, I wasn't at all clear on how that quote helped. From it, I couldn't tell if it was a worm gear, or a screw thread. Nor can I tell how much power the wrench has. Either in torque or in grip. Really, without the picture, I would have no real hint as to what it looked like. Nor how it worked. :(

Add to all of that the main decider in regards to strength and build will be material science related, and that description is borderline useless.

Seriously, gears don't just cut themselves. Threaded metal fittings are the advanced type theory for these tools.

[-]
I think you're right, but that's maybe not giving credit to the overall concept presented. The patent description text, even surrounded with the illustrations, still stands on its own. Yes, a picture paints a thousand words, but it would be nice if software engineers would write their descriptions or documentation as precise as that simple paragraph.

So don't miss the point of the article simply because maybe the patent illustration doesn't strictly hold. I'm personally tired of seeing lazy data structures that offer great amount of ambiguity in their use and type. This article hits on a great point that software folks can really stand to improve on.

Most development these days is sitting on top of a stack of abstractions, tools, frameworks, and library dependencies of highly varying quality and stability that are a couple of dozen layers deep. In this environment where software products and services maniacally duel each other for financial success atop these jenga towers made of jello, no such precision as Vannevar Bush recommends is possible.

And it only gets worse from here; more and deeper abstractions are inevitable.

[-]
I was doing some security evaluation work this week on a platform that surfaces information from functional tests of web applications. It had a somewhat obtuse onboarding process so I just copied one of their tutorial applications thinking that would be and easy way to get some data flowing through the tool.

Running on Amazon Linux it took nearly two hours for me to descend into the pits of ruby/rvm/node/puppeteer/headless chrome to get the damn thing ‘working’. Broken builds, missing tools, wrong major releases, segfaults, path issues, byzantine environment variable dependencies. I felt like Hal fixing the light bulb and I still have no idea what actually is going on when I run the tests. I just get the API requests I need and the rest feels like a black box in the form of nested Klein bottles.

I was really feeling my BOFH oats by the end of it and dismissing everyone that deals with that mess every day as a flock of sadists. I’ve since calmed down and realized that it’s probably not that bad if it actually is your day job. I just know that if I depended on that heap to actually do anything more than run some unit tests I would have years of acclimation in front of me.

For anyone unfamiliar with pipe wrench use, the genius of it is that the parts fit loosely and thus squeeze the pipe harder the more torque you apply to it. edit: you don't have to tighten the screw - that is just to get the jaws to about the right width.
[-]
You might be thinking of the Plumber wrench.
[-]
I hadn't heard of a plumber wrench before. It looks conceptually similar to vice grips, and squeezing the handles together produces the gripping force. Is that correct?

I am a little more familiar with pipe wrenches, though, and even though it isn't obvious from looking at the tool, it does grip harder the harder you pull on the handle. If you've never used one, I think it is worth the price of the wrench just to experience how it works.

[-]
Both use the jaw shape to bite into the pipe. The difference is that the plumber's wrench (never heard that name, the Swedish name translates directly as "pipe wrench") is that you can "help" it bite initially and that means it doesn't have to have as sharp teeth. The "american" pipe wrenches always seem to severely mar what they are used on.
This is more of an example of: every problem is solved with a wrench (strong typing).

But the real thing that we should discuss is to understand the context, the requirements and only then select our tools.

But no, it’s always hammers vs. wrenches on hacker news.

That's an easy comparison. If you want things that work, stick with wrenches. Software is for masochistic gamblers that like it when things blow up in their faces.
We did a pretty fun lab with some high school students to drive home how hard it is to convey precise information. They were in pairs, separated by an opaque screen. We gave one of each pair a flag of a random country, and they were supposed to describe it to the second of the pair who drew it according to their instructions.

Even simple flags got pretty botched. :)

Reminds me of the viral video where a dad asks him children to instruct him on how to make a peanut butter sandwich. If they were vague, he would exploit any ambiguity in the instructions against them - like "rub the knife on the bread" before it had any peanut butter on it :)

The military knows how to do this - and has a strong reason to. If your documentation cannot survive the death or resignation of the man, team or department that wrote it, you can't build generational knowledge. Look up the mil spec for chocolate cake (skips my mind where it is in my library) for example.

A $5 wrench can allegedly crack passwords: https://xkcd.com/538/
[-]
the technique costs more than 5 dollars though unless you have the "drug him" drugs sitting around already.
[-]
yeah you need at least $20 for the drugs, plus gas and wages for the driver to go pick them up. this doesn't even touch on depreciation / capital cost of the vehicle itself! also, what's the prevailing rent for an interrogation facility these days?
[-]
So can a $0 rock (or stick)
[-]
Rocks ain't free. Finding and picking up a rock usually requires at least half a minute, so if one takes an hourly wage to be $24 that makes the cost of obtaining a rock equal to... about 20 cents.
[-]
But there are two further considerations:

(1) The cost of the rock drops precipitously with your ability to pay. No matter what value you compute for the rock, you will find that the actual cost of a rock never rises above "negligible" for anyone who isn't severely handicapped, regardless of ability to pay.

(2) If you anticipate needing a rock in the future, you probably don't have to dedicate any time to finding one. You can just pick one up whenever it happens to be convenient.

[-]
It does not, Randall is just parroting a popular misconception that torture works. In reality you will not believe that a sadistic person beating you up is gonna stop after you say a password, and the more are you beaten and drugged the less likely you are to say that password, and criminals, police, intelligence and other thugs know it, they just use torture because they like it.
[-]
I think you are confused.

The _operational_ problem with torture is that the subject tends to tell you whatever unverifiable information they thing you want to hear. it is in this context that torture doesn't "work." the information is unreliable and thus low value.

For immediately verifiable information, such as a password, torture most assuredly does work and it is foolishness to pretend otherwise.

[-]
No that's not it, Randall is gesturing at utility theory -- the password is to something indifferent, so the person would decide that's it's not worth being beaten over (with the wrench) over. He's implying that the stuff being protected isn't that important.
[-]
Bring his kids in. He'll talk. Downvotes for unpleasant reality.
[-]
Whether he will "talk" is independent of whether torture works. With sufficient torture, I would tell you anything you want to hear. Want to know where the diamonds are? Sure, I can make up a dozen locations if it means those pliers stay away from me, even if I have no idea what diamonds you are talking about. Torture will always get answers. What it can't get is truth, or any way to distinguish truth from pleas.

And that is even independent of torture being inherently immoral.

[-]
This is assuming that the torturers are dumb (not true in the case of nation states) and that the information is not verifiable. This is not always the case. And the argument is that torture can and does work not that it always works. In the context of a password that I know you know and we can type in right now to make it stop, this will be effective.If you don't think the torture will ever stop and just want a 'fuck you' then you may keep quite. When your kids/family are brought in the 'fuck you' mentality goes out the window. Torture works, but it's like war. You have to go all in. This isn't a pro torture argument necessarily. But saying torture never works is dishonest and tanamount to saying I would keep all my secrets while being tutored to death, which I know I wouldn't.