Technological Revolutions and Cultural Revolutions: OSCON 2014

#oscon @oscon @timoreilly
Technological Revolutions
and Cultural Revolutions
Tim O’Reilly
OSCON
July 23, 2014
Wednesday, July 23, 14

“We know about all these new technologies. What we
don’t know is how to organize ourselves to use them
effectively.”
- An IT executive at Fidelity, during Q&A
after a talk I gave there in 2008

Open Source
“In ‘The Mythical Man-Month’, Fred Brooks observed that programmer time is
not fungible; adding developers to a late software project makes it later. He
argued that the complexity and communication costs of a project rise with the
square of the number of developers, while work done only rises linearly. This
claim has since become known as‘Brooks's Law' and is widely regarded as a
truism. But if Brooks's Law were the whole picture, Linux would be impossible.
Gerald Weinberg's classic ‘The Psychology Of Computer Programming’
supplied what, in hindsight, we can see as a vital correction to
Brooks. ...Weinberg observed that in shops where developers are not territorial
about their code, and encourage other people to look for bugs and potential
improvements in it, improvement happens dramatically faster than elsewhere.”
Eric Raymond, “The Cathedral and the Bazaar”
There is no question that tools - especially version control systems and the wide area communication and coordination capabilities of the internet -
were key to the open source revolution. But it was also a profound cultural revolution: a statement about how the world ought to be different.
And people - especially in the corporate world - struggled with those cultural differences. What? Show my code to the world. A lot of the
resistance was as much about embarrassment and trust and not knowing how to collaborate, rather than economics.

That was a hard cultural change, but now, with everyone from
Microsoft

to the White House sharing their code on Github, I think you can say that the cultural change is well underway.
Open source was also rooted in a culture of generosity and reciprocity. I remember asking Larry Wall why he gave away patch, and RN, and
Perl, and he said “I had gotten so much from others that it seemed only fair to give back.”
Now that we are all blinded by the lights of Silicon Valley, it’s easy to think that tech is all about making it big. But it’s really still about
giving something back in thanks for all we’ve received.

When I was asked that question at Fidelity, I also thought about the transformation of Amazon from an online bookstore into a
platform.

How Amazon Became a Platform
“[Jeff’s] Big Mandate went something along these lines:
1) All teams will henceforth expose their data and functionality through service interfaces.
2) Teams must communicate with each other through these interfaces.
3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of
another team’s data store, no shared-memory model, no back-doors whatsoever. The only
communication allowed is via service interface calls over the network.
4) It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter.
Bezos doesn’t care.
5) All service interfaces, without exception, must be designed from the ground up to be externalizable.
That is to say, the team must plan and design to be able to expose the interface to developers in the
outside world. No exceptions.
6) Anyone who doesn’t do this will be fired.”
Steve Yegge, in http://siliconangle.com/furrier/2011/10/12/google-engineer-accidently-shares-his-internal-
memo-about-google-platform/
How this happened was described by former Amazon engineer Steve Yegge in a leaked memo he wrote at Google, about how to become a platform.
Steve focused more on the technology side of this, but there was also a business organization side, as Amazon was organized into small
“two pizza teams” that reflected the Service Oriented Architecture of the platform in the service-oriented structure of the company.

DevOps
“…it’s not about making developers and sysadmins report to
the same VP. It’s not about automating all your configuration
procedures. It’s not about tipping up a Jenkins server, or
running your applications in the cloud, or releasing your
code on Github. It’s not even about letting your developers
deploy their code to a PaaS. The true essence of DevOps is
empathy.”
Jeff Sussna, “Empathy: The Essence of DevOps”
But there’s an even more important point to be made about what has now come to be called DevOps - the native cultural and business
practices of the cloud era. As Jeff Sussna wrote in a recent post....

Emergent Enterprise
“Promise theory doesn’t naively assume that all promises will be kept. Humans break their promises
all the time; machines (which can also be agents in a network of promises) just break. But with
promise theory, agents are aware of the commitments they’re making, and their promises are more
likely to reflect what they’re capable of performing. ...
... we know the estimates were made with accurate information by the agent responsible, not by
external wishful thinkers without a clue.
And a well-formed network of promises includes contingencies and backups. What happens if Actor A
doesn’t deliver on promise X? It may be counterintuitive, but a web of promises exposes its weak
links much more readily than a top-down chain of command. Networks of promises provide services
that are more robust and reliable than command and control management pushed down from above.”
Mark Burgess has another take on it, which he calls Promise
Theory.

Rescuing healthcare.gov
A team of engineers. They came in and worked tech
wizardry, right?
Maybe some of that, but a lot of the work was debugging the
communications failures that led the contractors to build
software components that didn’t work together.

18 hour days
100 days straight
Standup meetings focused on why people weren’t
able to keep the promises they’d made to each other
Mikey Dickerson
Google Site Reliability Engineer

Of course, what he found out was that healthcare.gov was
designed and delivered by a system that doesn’t allow developers
to make promises to each other, or to operations engineers, or to
end users. Instead, all of the promises are from policy makers
and politicians to other policy makers and politicians, and are
handed down from on-high through hard-coded specifications and
waterfall project management methodologies.
What the healthcare.gov rescue team brought was a cultural
revolution

If you want to understand more about that cultural revolution, this book is a great read - a novelized version of how DevOps was
brought to a failed IT project in a big manufacturing company.
It mirrors the healthcare.gov rescue very closely.

“…one privilege the insured and well-off have is to excuse the
terrible quality of services the government routinely delivers to
the poor. Too often, the press ignores — or simply never knows —
the pain and trouble of interfacing with government
bureaucracies that the poor struggle with daily. That can allow the
problems in those bureaucracies to fester.”
— Ezra Klein
But I want to take this story a bit further. One of the most important pieces about the healthcare.gov rescue was written by Washington Post
columnist (now vox.com founder) Ezra Klein. He wrote about how healthcare.gov was not an exception, but the rule, when it came to government
services.

And in that context, let’s talk a bit about food stamps, or as they’ve been renamed, the Supplemental Nutrition Assistance Program, or SNAP.
Recently, I heard an eye opening segment on the radio show Marketplace. Do you know that a huge proportion of food stamp dollars
are spent at stores like Walmart between midnight and 1 am on the one night that people’s SNAP cards are electronically refilled?
Who goes food shopping at midnight? People who haven’t eaten for a few days, that’s who.
So it really matters when you show up at the front of the line, and suddenly your SNAP card doesn’t work because of some
bureaucratic SNAFU!

Some of the Code for America Fellows went to work on this problem last year, in partnership with the Human Services Agency in San
Francisco.

“User needs. An empathetic service would ground itself in the concrete needs of concrete people. It’s
not about innovation, big data, government-as-a-platform, transparency, crowd-funding, open data,
or civic tech. It’s about people. Learning to prioritize people and their needs will be a long slog. It’s
the kind of change that happens slowly, one person at a time. But we should start.”
Jake Solomon, one of the Fellows, wrote an amazing piece about his experience, entitled People, Not Data. In it, he describes the problem: people
were falling out of the SNAP program because they didn’t comply with bureaucratic letters that they didn’t understand. No one can understand them. But
nobody who was implementing the program had ever themselves tried to comply with the rules and to respond to the instructions, until the Code for
America fellows they did that. They replaced these obscure letters with text messages that effectively said, “There’s a problem with your benefits. Call the
office!” As Jake said, “User needs...”
There’s a lot of talk in Silicon Valley about measuring and paying attention to users. We talk about Lean Startup and “Growth Hacking.” But there’s a
big difference to paying attention to user behavior so you can exploit it - say to drive ad clicks on in-app purchases - and to paying attention to it
so you can make a real difference in the lives of real people.

GDS
That’s why one of the bibles of user centered design, in my opinion, should be the UK government Digital Service’s Design Principles.
It’s about technology, yes, but far more importantly, it’s about putting technology to work for humans, not the other way around.
This is a huge cultural change for government, and that’s one reason it’s so interesting and challenging a set of problems to work on.

Cultural Change Required!
Cultural change is also required by many of the big disruptive startups and technologies we’re hearing about today.
The cultural changes that started with open source and the internet are far from over. There’s a lot more work to be done. But it’s
important to get beyond the Silicon Valley cult of disruption and to think about what we’re building towards.

“Uber is a $3.5 billion lesson in building
for how the world *should* work
instead of optimizing for how the
world *does* work” - Aaron Levie of
Box.net
There was a great tweet by box.net founder Aaron Levie talking about Uber... Aaron was talking about how we can use technology to
rethink the way a service like taxis ought to work for users. But there’s also a huge moral dimension to this statement - or there should be!
In the end, building towards the world we want - and making it a better one than the one we started with - is the only job worth doing.
I’m reminded of a Jack Handy Deep Thought I saw once. It said something like this: “If aliens came down and said ‘Show us your civilization’, we’d
say, “Come back in 20 years. This isn’t really our civilization. It’s just something we’re playing around with right now.’”
It’s about time we built a civilization we’d be proud to show. Developers today play a huge role in building our civilization. Let’s take that
responsibility seriously!

Technological Revolutions and Cultural Revolutions: OSCON 2014

Technological Revolutions and Cultural Revolutions: OSCON 2014

Recommended

More Related Content

What's hot

What's hot(18)

Viewers also liked

Viewers also liked(7)

Similar to Technological Revolutions and Cultural Revolutions: OSCON 2014

Similar to Technological Revolutions and Cultural Revolutions: OSCON 2014(20)

More from Tim O'Reilly

More from Tim O'Reilly(11)

Recently uploaded

Recently uploaded(20)

Technological Revolutions and Cultural Revolutions: OSCON 2014