Manufacturing guy-at-large.

Two great thought problems

Added on by Spencer Wright.

The other night I got into a wikipedia hole, prompted by xkcd's excellent "What If?" post "Twitter Timeline Height." Two great finds:

The German Tank Problem

i.e. "the problem of estimating the maximum of a discrete uniform distribution from sampling without replacement." From xkcd:

Allied troops faced a version of this problem in World War II. German tank parts had serial numbers, many of which were sequential (1, 2 ... N). Suppose they captured a random tank. If they determined it was Tank #27, then they can be sure that the Germans had made at least 27 tanks. It also told them there probably weren't millions of tanks; if there were, they would have been unlikely to get a two-digit serial number.

Wikipedia describes the discrepancy, in WWII, between serial number analysis and what traditional intelligence believed about German tank production:

According to conventional Allied intelligence estimates the Germans were producing around 1,400 tanks a month between June 1940 and September 1942. Applying the formula below to the serial numbers of captured German tanks, (both serviceable and destroyed) the number was calculated to be 246 a month. After the war, captured German production figures from the ministry of Albert Speer showed the actual number to be 245. 

In case that's not clear: Spies (who were presumably fooled by counterintelligence) were saying that Germany was producing about 1,400 tanks per month, but serial number analysis said that it was closer to 246. The actual number was 245.  

The Two Envelopes Problem

From Wikipedia:

You have two indistinguishable envelopes that each contain money. One contains twice as much as the other. You may pick one envelope and keep the money it contains. You pick at random, but before you open the envelope, you are offered the chance to take the other envelope instead.
It can be argued that it is to your advantage to swap envelopes by showing that your expected return on swapping exceeds the sum in your envelope. This leads to the paradoxical conclusion that it is beneficial to continue to swap envelopes indefinitely. 
A partial explanation: There's a 50-50 split here - either you've got the smaller envelope or the larger one. Let's say there's $20 in your envelope:  
The probability of either of these scenarios is one half, since there is a 50% chance that I initially happened to select the larger envelope and a 50% chance that I initially happened to select the smaller envelope. The expected value calculation for how much money is in the other envelope would be the amount in the first scenario times the probability of the first scenario plus the amount in the second scenario times the probability of the second scenario, which is $10 * 1/2 + $40 * 1/2. The result of this calculation is that the expected value of money in the other envelope is $25. Since this is greater than my selected envelope, it would appear to my advantage to always switch envelopes.
This is totally weird. There are a few purported solutions on the wikipedia page, most of which elude me.  
The takeaway: I really need to get into some Bayesian probability theory. Stat. 

Ryan Tomayko: Your team should work like an open source project

Added on by Spencer Wright.

Last week I linked to a quote by Zach Holman on getting people interested in your projects. His original text included a link to an excellent post by Ryan Tomayko , which argues for structuring your team in an opt-in format, much like open source projects. I've been reading more and more to this effect recently, but Tomayko makes a really great case. A few excerpts (n.b., I've reformatted a few of these due to weirdness while composing this post {grr...}. The spirit should be unchanged. Also, emphasis is mine.):

What we're learning at GitHub is that opting in to open source project constraints often results in better natural survivability characteristics for many types of business, product development, and operations activities. That is to say, processes designed to conform to open source constraints results in a project that runs well, attracts attention, and seems to be self perpetuating where the same project structured more traditionally requires much more manual coordination and authoritative prodding. 

Tomayko excerpts the GitHub product development documentation at length:

The processes and basic rules for communication on github.com projects are roughly the same as those of an open source project. Mainly, that development and operations follows these constraints where sensible: Discussion, planning, and operations process should use a high fidelity form of electronic communication like email, github.com, or chat with transcripts wherever possible. Avoid meatspace discussion and meetings...Work should be visible and expose process. Work should have a URL. It should be possible to move backward from a piece of product or a system failure and understand how it came to be that way. Prefer git, issues, pull requests, mailing lists, and chat with transcripts over URL-less mediums...Almost no part of the product development process requires that one person interrupt another's immediate attention or that people be in the same place at the same time, or even that people be in different places at the same time. Even small meetings or short phone calls can wreck flow so consider laying it out in (a thought out) email or sending a pull request instead.

And then goes on to "predict the decline of the office as the center of planning, coordination, and communication for software development organizations," while acknowledging their utility in developing strategy and celebrating milestones & victories: 

Lastly, working face-to-face in meatspace has proven extremely valuable in matters of strategic thinking and, obviously, for developing personal relationships, two things which are vital to a company's success.

I suspect that more and more product development cycles will move this way in the future, and think that the results will be overwhelmingly positive.

Intentions

Added on by Spencer Wright.

Last week, director James Toback appeared on Alec Baldwin's excellent podcast, Here's the Thing. They talked a lot about the benefits of having full creative control over projects, but the big takeaway for me was on being forthright about your intentions. Toback paraphrases Karel Reisz's way of working:

Decide what you want, and then make your wishes clear to everybody you're working with. 

I think this is fantastic advice. 

Water will find its level.

Added on by Spencer Wright.

This week's 99% Invisible  includes a short piece on the Strowger Switch, the 1878 invention that allowed telephone calls to be connected without a manual operator. Poignantly, Roman includes a bit about the inventor's reaction to the plight of those operators whose jobs would be eliminated due to his invention. His response, I think, is perfectly appropriate, and reminds me of this chart from McKinsey's report on disruptive technologies. From Roman's piece:

La Porte Indiana became the first place to have automatic operator-free telephone dialing. In a speech at the unveiling of the La Porte telephone exchange, the cantankerous Strowger addressed the issue of the 'hello girls' - the operators who would lose their jobs because of his automated switch. "I am often told that the the telephone girls would be angry with me for robbing them of their occupation. In reply, I would say that all things will adjust themselves to the new order. Water will find its level. The telephone replaced the messenger boy, as this machine now displaces the telephone girl. Improvements will continue to the end of time. Strike where they may."

Voyager

Added on by Spencer Wright.

The 116 images onboard Voyager 1 (the Golden Record) are absolutely fascinating. They tell a weird and compelling story about humanity and the way we understand and process the world. Below are a handful of them, found on Web Odysseum. 

I would love to write something more interesting here, but really you should just listen to this episode of Radiolab and read the excellent Wikipedia entry for the Golden Record.

Chuck Klosterman on agreeing with the Future

Added on by Spencer Wright.

 Chuck Klosterman from his 2013 book "I Wear the Black Hat: Grappling with Villains (Real and Imagined)." The key (to me) is the second paragraph; emphasis mine. (n.b., the text below is transcribed (carefully) from the audiobook. Punctuation may vary.)

And the worst part is that there is no other option. If a father stops his son from embracing the online universe, he is stopping him from becoming a competitive adult. It's like refusing to teach him how to drive a car, or boil water. You may worry about al the ancillary consequences, but you can't take away the experience. Avoiding the internet is akin to avoiding everything that matters. This is even true for adults. An author I know once explained why writing became so much more difficult in the 21st century: "The biggest problem in my life," he said, "is that my work machine is also my pornography delivery machine." The future makes the rules.
The future makes the rules, so there's no point in being mad when the future wins. In fact, the easiest way for any cutthroat person to succeed is to instinctively and relentlessly side with the technology of tomorrow - even if that technology is distasteful. Time will eventually validate that position. The only downside is that until that validation occurs, less competitive people will find you annoying and unlikeable. The future will retire undefeated, but it always makes a terrible argument for its own success.
The argument is inevitably some version of this: You might not like where we're going, and tomorrow may be worse than yesterday, but it's still going to happen whether you like it or not. It's inevitable. And this is what people hate. They hate being dragged into the future. And they hate that technocrats remind them that this is always, always, always happening. We tend to dislike cultural architects who seem excited that the world is changing, particularly when those architects don't seem particularly concerned whether those changes make things worse. They know they will end up on the right side of history, because the future always wins. These are people who have the clearest understanding of what technology can do, but no emotional stake in how its application will change the lives of people who aren't exactly like them. They know the most, and they care the least, and they kinda think that's funny. Certainly, this brand of technophobia has always existed. As early as 1899, people like H.G. Wells were expressing apprehension about a future "ruled by an aristocracy of organizers, men who manage railroads and similar vast enterprises." But this is different. This is about the kind of person who will decide what the future is.

Seth Bunsen's Coffee experiment

Added on by Spencer Wright.

OMFG this is great! 

Basically, this guy did an informal (but blind, controlled, and apparently statistically serious) experiment to determine which variables affected people's feelings about a cup of coffee. The short of it:

  • People slightly prefer spinning-blade grinders to burr grinders
  • People actually prefer Aeropress coffee to drip brew. 
  • Seth Bunsen is awesome. 

A few takeaways (emphasis mine):

My longest running experiment centers on coffee grinders. A common belief among coffee pundits is that good coffee depends on good grinding. Specifically, coffee ground with a burr grinder purportedly tastes better because it grinds the beans more uniformly and doesn’t over-heat the grounds like traditional blade grinders. The experiment I setup tested this claim by brewing coffee using a burr grinder or a blade grinder and scored which of the two cups subjects preferred...Based on this analysis, subjects did not show a statistically significant preference to coffee brewed from a blade grinder or burr grinder. Therefore, I opted to save a few hundred dollars and not invest in a burr grinder based on these experiments.

And: 

Another variable I was interested in understanding was the impact of different brewing methods on flavor preferences. I wanted to know if house guests preferred coffee brewed via drip-extraction versus coffee brewed with the Aeropress. I setup my experiment as previously described and scored the number of house guest who preferred each brewing method. The objective of this analysis was similar to the burr grinder experiment, but this time I wanted to compare preferences between two different brewing methods...I observed that 15/20 or 75% of subjects preferred coffee from the Aeropress...Thus, there is reason to believe that the Aeropress may, in fact, produce better tasting coffee than drip-extraction.

And: 

I’ve examined other coffee variables using a similar experimental approach and found only a few factors that had any measurable effect on coffee flavor in isolation. For example, variables like bean freshness or bean purveyor has little effect on flavor...Until I obtain convincing evidence that support investing additional money in brewing accouterments, I see little reason to deviate from this system. In the words of Carl Sagan, extra-ordinary claims require extra-ordinary evidence.

This is exactly the kind of study I want to do with wine. I'd also love to expand upon Bunsen's coffee experiments to include Moka pot, French Press, and - why not - Folgers. 

With thanks to Marco Arment for the link.

 

3D printing & Material specifications

Added on by Spencer Wright.

I've been working on a few product ideas that would be 3D printed from titanium or stainless steel, and the methods by which 3D printed parts are specified has been on my mind throughout the process. The following passage, taken from the IDA Science and Technology Policy Institute's 2012 report "Additive Manufacturing: Status and Opportunities" sums up my feelings quite nicely. Note: "AM" refers to "additive manufacturing, which is a slight superset to the processes casually described as "3D printing." Emphasis is mine.

AM technology has made significant strides over the past 25 years, but technical challenges related to materials, equipment, and applications remain. Many of the challenges described in this section, which have commonly been discussed in workshops or publications, are the focus of ongoing research in government agencies or industrial organizations. In some cases, the topics may be underfunded by the private sector and could benefit from new or additional Small Business Innovative Research funding. 
Information is needed on material properties for different processes, but who would maintain such a database and which data should be publicly available are unclear. Before the AM industry can fully transition to offering viable manufacturing solutions, specifications are needed that provide mechanical properties data for available materials, as well as more detail on how parts made from these materials perform (Campbell et al. 2011). Engineers and designers cannot design without fully understanding the properties of the materials used to manufacture the parts being designed. If the properties for AM materials are not available, designers will not consider additive manufacturing as a method of manufacturing. With so many AM processes and materials currently available, the creation of comprehensive specifications is a resource-intensive endeavor, requiring the involvement of research organizations and system and material manufacturers (Kinsella 2011). 

Worth noting: despite knowing the difference between yield strength and ultimate tensile strength, I am not an engineer. But having access to full material data - as well as data on how parts made of that material perform - would be incredibly useful, even to a dullard like me.

Zach Holman

Added on by Spencer Wright.

via Timoni. Original text on GitHub.

I’ve had a few really great ideas over the years of really awesome things I’ve wanted to work on, and sure, you get people saying “yeah that’d be awesome to have!” But then I couldn’t find anyone to work on it with me. That’s a huge indicator. It’s easy to get people to agree with you, but if you can’t convince them to donate their time to make the vision a reality, it’s a massive signal that what you’re doing isn’t great.

-Zach Holman

Hackweek Day 5

Added on by Spencer Wright.

Friday was Rubyday.  

On Thursday, Zach and I had banged out about a third of the Codecademy Ruby class. It was a good primer on Ruby syntax and basic usage, and I'll be completing it this week. But we wanted to get a little web dev practice in, and so on Friday we went through the "Getting Started with Rails" tutorial on RailsGuides.

The tutorial is great. My method is to hand-type (not copy/paste)  every section of code. I keep two BASH terminal windows open and got the Sublime Text command line tool running so I can quickly create files and edit them without touching my mouse.  There were a few anomalies in the tutorial that I had a little trouble with, but googling solved them in short order (It seems that the guide is written for Ruby 1.9.3, and the syntax for 2.0.0 requires a few changes).

By the end of the day, I had created a simple blog app and was hosting it locally. I should note that I don't totally understand the structure of all of what I did, but I got a bit of debugging in, and just typing the entire thing out really did help develop a basic feel for the framework.  I think it's also worthwhile to go through simple exercises like this, just to understand how little you know about the basic tools (e.g. blogs) that you get used to using on a daily basis. 

The net effect of the week: Every week should be like this. Which is to say, every week is hustle week.  

Of course, shit will get in the way. This week I need to be out of town for a couple days, and that'll inevitably throw me off a bit. But I will finish the Codecademy Ruby class. And I will make progress on my seatpost project, and I will move on to the Ruby On Rails Tutorial book. This last one is the most significant of the three, but I would hope to complete it in a matter of a week.

:Sigh: 

You know, for three years I worked alone building bikes. It was an incredibly lonely, frustrating time of my life, and in the end I allowed those factors to prevent me from learning all the relevant lessons that were available to me. I didn't hustle hard enough; I had a hard time learning things quickly enough. I'm learning more quickly now, and hustling harder. And though the burn will remain slow for a while, I'm betting that the blaze that results will be quite a bit more satisfying.

Hamish McKenzie on content providers

Added on by Spencer Wright.

Hamish McKenzie, writing on Pandodaily about Spotify and the future of content providers.

I’ve said it before, and I’ll keep saying it until the publishing world has fully adapted to this ongoing tectonic shift in media: In a world in which digital content is increasingly being distributed via all-you-can-eat platforms like Spotify, Netflix, and Oyster at the same time as social networks like Twitter, Facebook, Reddit, Digg, and email are pushing content to people rather than the other way around, and as we increasingly consume media on one-thing-at-a-time mobile devices, the “bundle” doesn’t matter nearly as much as it did in the print or Web 2.0 eras.
Homepages are becoming less relevant.
Stories have to stand on their own.
Content owners have to get used to the idea that their carefully curated packages are being blown to bits. 

Jeff Bezos on being misunderstood

Added on by Spencer Wright.

Amazon's Jeff Bezos at the Aspen Institute in 2009. Via The Motley Fool (emphasis mine).

If you look at where we are today, it's half luck, half good timing, and the rest has been brains. So in some ways, I think we have not been tested. You know, we were unprofitable for so long, and people predicted our demise for so long, that we did develop thick skins - which I think is very valuable for invention, because often times invention requires a long-term willingness to be misunderstood. You do something that you genuinely believe in, that you have conviction about, but for a long period of time, well-meaning people may criticize that effort. When you receive criticism from well-meaning people, it pays to ask, 'Are they right?' And if they are, you need to adapt what they're doing. If they're not right, if you really have conviction that they're not right, you need to have that long-term willingness to be misunderstood. It's a key part of invention.

 

Jeff Bezos on regrets

Added on by Spencer Wright.

Amazon's Jeff Bezos, quoted by The Academy of Achievement in 2008. via The Motley Fool (emphasis mine).

So, it really was a decision that I had to make for myself, and the framework I found which made the decision incredibly easy was what I called -- which only a nerd would call -- a "regret minimization framework." So, I wanted to project myself forward to age 80 and say, "Okay, now I'm looking back on my life. I want to have minimized the number of regrets I have." I knew that when I was 80 I was not going to regret having tried this. I was not going to regret trying to participate in this thing called the Internet that I thought was going to be a really big deal. I knew that if I failed I wouldn't regret that, but I knew the one thing I might regret is not ever having tried. I knew that that would haunt me every day, and so, when I thought about it that way it was an incredibly easy decision. And, I think that's very good. If you can project yourself out to age 80 and sort of think, "What will I think at that time?" it gets you away from some of the daily pieces of confusion. You know, I left this Wall Street firm in the middle of the year. When you do that, you walk away from your annual bonus. That's the kind of thing that in the short-term can confuse you, but if you think about the long-term then you can really make good life decisions that you won't regret later.