Comment by jacobolus | Hacker News Reader

Comment by jacobolus | Hacker News Reader

Parent Full thread

This has some cute anecdotes, but is overall a pretty intellectually flimsy argument. The summary is basically “when given a concrete metric, humans are really good at optimizing to it. These improvements compound, and dramatic qualitative changes can result from many tiny incremental steps.”

For anyone in computing, where we’ve seen improvement of 5+ orders of magnitude in the past 50 years, this should hardly be a new insight.

No effort is made to examine the trade-off between tackling tiny marginal problems vs. rethinking more fundamental assumptions and practices. Likewise, there’s no consideration of whether the metrics involved (e.g. reduction of liability insurance premiums, number of hot-dogs eaten during a contest, success at exams, or toolbar click-through rate) are the most important things to optimize, or indeed if by spending great effort optimizing for those specific criteria we might create unexpected costs and side effects that we won’t necessarily even know about.

I shouldn’t be too hard on the author I guess... he’s just trying to promote his new self-help book.

I think the contrast shouldn't be with rethinking fundamental assumptions, which is another good but rare activity. It should be with assuming that things are pretty much as good as they get, or assuming that small wins aren't worth bothering with. Because that's where a lot of businesses are all the time. Computer hardware is very much the exception.

If you want an example of where this matters, the car industry is a great example. In Rother's "Toyota Kata", he has a graph showing productivity per worker among big auto firms. The large car companies all rise together until the 60s and then plateau. Toyota, which had a very strong focus on continuous improvement just kept on rising for decades. This enabled them to go from Japan's post-war decimation to become the world's largest car maker while the others stagnated.

And I should add that continuous improvement is a good way to drive fundamental rethinking. The only way to get long-running continuous improvement is to pay a great deal of attention to how things actually are working. Eventually you will say, "Well, now that we've solved a bunch of little things, the biggest bottleneck is X". But changing X forces fundamental reevaulations.

For example, consider software release. Unreleased software is like inventory just sitting around the factory. You've paid money to make it, but it's not earning any money for you.

Years ago, quarterly and annual release cycles were common. The last part of the cycle was when a large, manual QA team would beat up the whole product. As we have kept squeezing release cycles, this has forced all sorts of innovation. At my last couple of companies, we've used continuous deployment, where every commit to master is automatically tested and deployed to production. These small teams averaged a few releases a day and had no QA people. Etsy has 50+ releases a day [1]. If you were to describe this to people 20 years ago, they'd call you insane; it's a fundamentally different view of how software gets made. But we've gotten there via 15 years of continuous improvement.

[1] http://www.infoq.com/news/2014/03/etsy-deploy-50-times-a-day

To be fair, quarterly and annual release cycles were common when software was a physical product. Games had to sell retail, and enterprise software still needed to deliver disks. Until the early 2000s there was no point in continuous integration because your release process still had to be waterfall - you were gated by extremely slow physical processes like retail outlet logistics.

Once continuous deployment to the end user was possible (via the internet), the industry started following suit. And nowadays there is still something similar for iPhone developers - you're gated by the Apple app store, which doesn't have to be slow, but somehow still is. (This has important implications like having to backload a huge amount of testing before app submission because you can't be certain of how quickly you'll be able to release a frontend patch).

Sure, the shift in delivery mechanisms provided a lot of incentive to move to faster deployment.

But I should note that a great deal of software in ye olden dayes was in-house software, and that still ran on 3-18 month cycles. And that wasn't because of technological limitations; my dad was delivering new versions of software every few days even in the 70s. It's just that the conceptual model and the dogma pushed in the direction of long, heavily-planned release cycles. The Internet's main contribution here was to make short cycles not only possible for commercial releases, but competitively advantageous in an obvious way.

Lol. This was a fantastic comment. I love the ending. We really are living in strange times. It's as if everyone is utterly intent on working but can't find the time to figure out what they ought to do. Everyone seems increasingly scared. I may be projecting or just increasingly aware. It's like they know they don't know but can't face it or resolve it. They just keep doing the bullshit until they embrace it. Our potential is so ripe. It's sad.

This is because the social contract still says we should all be working (and be rewarded for that work) but there is leas and less 'real' work around. So people invent 'work' like tracking marginal improvements, which may be helping with one small thing but completely missing out the big picture (we shouldn't be encouraging world class athletes to compete at such levels anymore as it is no longer healthy for them and sets unrealistic expectations for everyone else)

I love these sorts of negative assessments of greatness. I fucked over so many kids in math growing up. They came to believe they'd never be good at it because I worked ahead and they didn't realize it. Maybe I can't make up for the output I squashed. I'll never know. :(

>as it is no longer healthy for them

I'm not sure if this is sarcasm or not, but I'll go out on a limb and say that those athletes are far, far more healthy than the people slumping over their keyboards in an office all day (which is probably 90% of this message board).

Athletes are optimized to perform, but they can still be unhealthy in that many of them get injured, take unsafe risks, etc.

For example, bodybuilding is known to be relatively safe and healthy in terms of training injuries and average-case benefits of training, but top bodybuilders - and even marginal amateurs - are not healthy, they are pushing their body way out of balance for pageantry; just listen to this guy [0] go on for thirty minutes about his pre-contest drug program. Likewise, basketball optimizes for tall people who can move fast, but basketball injuries are an everyday event, because tall people who move fast overstress their joints and ligaments.

Where athletes are healthy, it's because health and performance happen to align together. There are plenty of people here who want to optimize their mental abilities, and will go to the same extremes as any athlete. Paul Erdős was known for running amphetamines[1] to aid his ability to concentrate. Today you hear about folks using prescription pharmaceuticals for the same reasons.

[0] https://www.youtube.com/watch?v=lF4zL_BdePc [1] https://en.wikipedia.org/wiki/Paul_Erd%C5%91s#Personality

Whether it's true or not, I don't think we ask those sort of questions often enough.

Those NFL concussions don't seem so great.

Someone finally explained to me why sports analogies rarely work: in business (and in life) you get to make up the rules of your own game. Which is why it's possible to take large leaps which aren't as possible when everyone is playing by the same rules.

One of the most important insights of Darwinism is that there's little, if any, discontinuity between "microevolution" and "macroevolution". At least in biology.

Of course, in human activities the "environment" is also man-given. We're able to challenge structural assumptions in, say, engineering, because broader maps (possibly showing that we're grinding at local optima) have been made by physicists, mathematicians or even philosophers. But these too are working at their "microevolution".

There's never a context where someone is thinking hard at the "fundamental assumptions" of an applied problem and brings a 100-year leap in the basic science, for example.

>There's never a context where someone is thinking hard at the "fundamental assumptions" of an applied problem and brings a 100-year leap in the basic science, for example.

I would argue that Turing tackling Hilbert's program qualifies. And I suspect, that the concept of DNA, and the concept of evolution itself qualify as well.

>Brailsford believed that if it was possible to make a 1% improvement in a whole host of areas, the cumulative gains would end up being hugely significant.

If there are ten components that make up the total, and you make a 1% improvement in each of those components, the cumulative gains for the total is... 1%. Maybe I'm being pedantic; I realize the main point is probably something closer to what the parent comment articulated. As worded in the article is not accurate.

Consider if the components interact multiplicatively, not additively.

>No effort is made to examine the trade-off between tackling tiny marginal problems vs. rethinking more fundamental assumptions and practices.

So what? That isn't what the article and book is about.

Maybe you should spend some time writing the book you seem to want to read, instead of criticizing a book for not including things, when you haven't even read it.

Reply on news.ycombinator.com