Anzen. It helped a 100-year-old, 60,000-person aluminum manufacturer regain its greatness. It powers the culture, operations and massive growth of an online artisan marketplace. It’s the common denominator of every great Lean and Agile principle and practice. Anzen is the Japanese word for safety.
Every day, your time, money, information, reputation, relationships and health are vulnerable. Anzeneers protect people from injuries, hazards or near-misses by establishing anzen in relationships, workspaces, codebases, contracts, processes, products and services.
When anzen is present in a software product, everything just works: people regularly use and recommend the product; engineers modify it without fear; it contains few defects; it can be deployed with ease; it is immune from threats; and it helps protect the organization’s finances, reputation and investors. Anzen is a gateway to habitual excellence. Anzeneers approach failure as an opportunity to introduce more anzen into their culture, practices, and tools.
In this talk you will learn what anzen is, how it promotes safe risk taking, how to identify faux safety, when it can be taken too far, challenges of growing an anzen culture and what it means to be an Anzeneer.
Google and eBay operate some of the largest Internet sites on the planet, and each maintains its leadership through continuous innovation in infrastructure and products. While substantially different in their detailed approaches, both organizations have lessons to teach. This keynote tells several war stories from Google and eBay focusing on performance, consistency, resilience, and autoscaling. It details hard-won lessons learned in scaling those companies' infrastructures, organizations, and technology stacks. It finally describes how we put those lessons into practice in the context of real-time games at KIXEYE, and offers concrete suggestions you can apply to your own organization.
What do unicorns, flying pigs, and bug-free software have in common? It's simple: they're all mythic fantasies.
Consider this: every piece of software you've ever used has had bugs in it, including the software you've written. Bugs get deployed to production all the time. Why is this the case? Why do we struggle so much to make bug-free software?
It turns out there are deep fundamental reasons why this is the case, and these reasons are not unique to software development. There are lessons we can take from thinkers outside software development – from people who lived many centuries ago – to understand why there are limitations on what humans can know.
By embracing your limitations instead of fighting them, you'll discover why the key to making good software is to avoid the trap of trying to make perfect software.
The loop is showing its age. Long used to process collections and control program flow, the loop is becoming a liability. A future of highly parallel and concurrent programs is unfolding in front of us, and it's becoming clear that the loop is too primitive for these problem domains.
Whether you are a front-end web developer or a cloud developer or architect, you need to know what comes after the end of the loop.