You may be concerned with the quality, size, or performance of a site or app, but are you as concerned with its power consumption? Components used to render what you see on the screen can consume more processing time and battery life than is really necessary. Estelle Weyl shares 5 easy ways to improve battery life in your app. Read more...
In this episode, John Allspaw talks in-depth about blameless postmortems and creating a just culture.
When you’re dealing with complex systems, failure is going to happen; it’s a given. What we do after that failure, however, strongly influences whether or not that failure will happen again. The traditional response to failure is to seek out the person responsible and punish them accordingly — should they be fired? Retrained? Moved to a different position where they can’t cause such havoc again?
John Allspaw, SVP of technical operations at Etsy and co-chair of the O’Reilly Velocity Conference, argues that this “human error” approach is the equivalent of cutting off your nose to spite your face. He explains in a blog post that at Etsy, their approach it to “view mistakes, errors, slips, lapses, etc., with a perspective of learning.” To that end, Etsy practices “blameless postmortems” that focus more on the narrative of how something happened rather than who was behind it, and that remove punishment as an outcome of an investigation.
The 13 principles in the U.S. CIO's Digital Services Playbook are applicable for everyone.
Whenever I hear someone say that “government should be run like a business,” my first reaction is “do you know how badly most businesses are run?” Seriously. I do not want my government to run like a business — whether it’s like the local restaurants that pop up and die like wildflowers, or megacorporations that sell broken products, whether financial, automotive, or otherwise.
If you read some elements of the press, it’s easy to think that healthcare.gov is the first time that a website failed. And it’s easy to forget that a large non-government website was failing, in surprisingly similar ways, at roughly the same time. I’m talking about the Common App site, the site high school seniors use to apply to most colleges in the US. There were problems with pasting in essays, problems with accepting payments, problems with the app mysteriously hanging for hours, and more.
Guidelines to maximize, allocate, and use resources strategically
Step one: Build your case
Before you can instill a culture of performance, you first need to demonstrate the value of strong web performance to your colleagues and superiors. To do that, you must build a case based on business standards that everyone can relate to, specifically by demonstrating the clear link between web performance and revenue. Calculate how much revenue you would lose if your site was down for hours, or even minutes. Ask how much time IT spends fixing problems when they could be working on other issues. Figure out what your competitors’ web performance is like and how yours compares (if it’s better, you have to keep up; if it’s worse, it’s an opportunity to take advantage of their weakness).
A collection of must-see keynotes from Velocity Santa Clara, with bonus videos of some of the best sessions.
Editor’s note: this post originally appeared on Steve Souders’ blog; it is published here with permission.
Velocity Santa Clara was our biggest show to date. There was more activity across the attendees, exhibitors, and sponsors than I’d experienced at any previous Velocity. A primary measure of Velocity is the quality of the speakers. As always, the keynotes were livestreamed — the people who tuned in were not disappointed. I recommend reviewing all of the keynotes from the Velocity YouTube Playlist. All of them were great, but here’s a collection of some of my favorites.
Start. Here. Scott Hanselman’s walk through the evolution of the web and cloud computing is informative and hilarious:
PayPal has gone through a cultural transformation with radical transparency as a cornerstone of the plan.
Three years ago, PayPal was growing exponentially, staying profitable and was considered the most successful online payments company in the world. This should have been the recipe of a company that was attracting top talent across the globe, and keeping their core engineers happy, thriving, and innovative. But, at the time, the PayPal engineering team wasn’t where they needed to be to stay ahead of the curve — they didn’t have the process, the tools, or the resources to extend their talent and stay engaged in creating amazing products and services.
Leadership had encouraged the formation of engineering silos to “concentrate expertise,” but this made it incredibly challenging to get things done. At the same time, popular services such as Google and Amazon were raising the bar for everybody. All businesses — not just software-focused businesses — needed to have websites (and mobile apps) that were snazzy and responsive in addition to being reliable. PayPal engineering needed to push the proverbial envelope to stay competitive in a fierce and unrelenting industry landscape.
For PayPal, the transformation started at the edge of the stack. The Kraken project, which was started by an internal team to support a new checkout system, proved that an open source platform could reduce time to market and still perform at scale. This was achieved largely in spite of the silo culture that ran rampant and tended to restrict innovation and creativity. Support from senior management and perception of less risk at the edge of the stack helped the project and ultimately unleashed a gold rush of interest in repeating the win with releases of internally developed improvements to other open source projects. When I came into PayPal, I received an avalanche of mail from teams who wanted to “open source something.”