- How to Make Moonshots (Astro Teller) — Expecting a person to be a reliable backup for the [self-driving car] system was a fallacy. Once people trust the system, they trust it. Our success was itself a failure. We came quickly to the conclusion that we needed to make it clear to ourselves that the human was not a reliable backup — the car had to always be able to handle the situation. And the best way to make that clear was to design a car with no steering wheel — a car that could drive itself all of the time, from point A to point B, at the push of a button.
- Billion-Dollar Math (Bloomberg) — There’s a new buzzword, “decacorn,” for those over $10 billion, which includes Airbnb, Dropbox, Pinterest, Snapchat, and Uber. It’s a made-up word based on a creature that doesn’t exist. “If you wake up in a room full of unicorns, you are dreaming,” Todd Dagres, a founding partner at Spark Capital, recently told Bloomberg News. Not just cute seeing our industry explained to the unwashed, but it’s the first time I’d seen decacorn. (The weather’s just dandy in my cave, thanks for asking).
- What Impactful Engineering Leadership Looks Like — aside from the ugliness of “impactful,” notable for good advice. “When engineering management is done right, you’re focusing on three big things,” she says. “You’re directly supporting the people on your team; you’re managing execution and coordination across teams; and you’re stepping back to observe and evolve the broader organization and its processes as it grows.”
- cxxnet — “a fast, concise, distributed deep learning framework” that scales beyond a single GPU.
From careers to culture to code, here are key insights from the O'Reilly Software Architecture Conference 2015.
Experts from across the software architecture world came together in Boston for the O’Reilly Software Architecture Conference 2015. Below we’ve assembled notable keynotes, interviews, and insights from the event.
Software architects: post-“post-useful”
The old notion of a software architect being a non-coding, post-useful deep thinker is giving way to something far more interesting, says Neal Ford, software architect and meme wrangler at ThoughtWorks. “Architecture has become much more interesting now because it’s become more encompassing … it’s trying to solve real problems rather than play with abstractions.”
Empathy, communication, and collaboration across organizational boundaries.
I might try to define DevOps as the movement that doesn’t want to be defined. Or as the movement that wants to evade the inevitable cargo-culting that goes with most technical movements. Or the non-movement that’s resisting becoming a movement. I’ve written enough about “what is DevOps” that I should probably be given an honorary doctorate in DevOps Studies.
Baron Schwartz (among others) thinks it’s high time to have a definition, and that only a definition will save DevOps from an identity crisis. Without a definition, it’s subject to the whims of individual interest groups, and ultimately might become a movement that’s defined by nothing more than the desire to “not be like them.” Dave Zwieback (among others) says that the lack of a definition is more of a blessing than a curse, because it “continues to be an open conversation about making our organizations better.” Both have good points. Is it possible to frame DevOps in a way that preserves the openness of the conversation, while giving it some definition? I think so.
DevOps started as an attempt to think long and hard about the realities of running a modern web site, a problem that has only gotten more difficult over the years. How do we build and maintain critical sites that are increasingly complex, have stringent requirements for performance and uptime, and support thousands or millions of users? How do we avoid the “throw it over the wall” mentality, in which an operations team gets the fallout of the development teams’ bugs? How do we involve developers in maintenance without compromising their ability to release new software?
How do we manage systems that are too large to understand, too complex to control, and that fail in unpredictable ways?
“What is surprising is not that there are so many accidents. It is that there are so few. The thing that amazes you is not that your system goes down sometimes, it’s that it is up at all.”—Richard Cook
In September 2007, Jean Bookout, 76, was driving her Toyota Camry down an unfamiliar road in Oklahoma, with her friend Barbara Schwarz seated next to her on the passenger side. Suddenly, the Camry began to accelerate on its own. Bookout tried hitting the brakes, applying the emergency brake, but the car continued to accelerate. The car eventually collided with an embankment, injuring Bookout and killing Schwarz. In a subsequent legal case, lawyers for Toyota pointed to the most common of culprits in these types of accidents: human error. “Sometimes people make mistakes while driving their cars,” one of the lawyers claimed. Bookout was older, the road was unfamiliar, these tragic things happen. Read more…