There is a question you have answered several times a day,at least since your teens.

It’s the question you hear from everyone you meet, from all of nature.

It’s the question you ask yourself when you look in the mirror, or look down from a tall building.

It’s the question you’ll ask yourself in the moment before you die.

Your answer to this single question, so common you’ve probably never even noticed it, shapes everything about you, and determines your success.

It is the most important minute of your life, and it is the doorway to your future.

Of all the ideas of Lean, batch size reduction is the most important economically. Yet, few product developers understand it. Manufacturers handle physical objects and they can easily see their batch sizes. Developers handle information and batch size is frequently invisible. In fact, 97 percent of product developers have no systematic program to reduce batch size. In this keynote Don Reinertsen will discuss why batch size reduction is such an important tool, and how you can approach it with a bit of science. He will show you why popular manufacturing ideas like one-piece flow can make little sense in product development and how to think about the economics of batch size.

Would you believe that the image below of the famous Utah Teapot is rendered using just div elements and CSS without any OpenGL, WebGL, Canvas, or other “real” graphics capabilities?

In this fun talk, we will explain this glorious hack we first learned from a blogpost by Jeff Lau aka Useless Pickles, and that we subsequently used as a demo for our IL to JavaScript compiler project.

While the original Live Labs project has long gone to the happy hunting grounds of technology, we salvaged this little pearl as a timeless demonstration of doing a lot with very little.

GitHub consists of a bunch of employees who have worked at other companies in the past and despised it. Okay, maybe they weren’t all terrible jobs, but a lot of us remain skeptical of most software development practices. We do things differently at GitHub. We don’t have meetings, we don’t have managers, we don’t do traditional code review, and we aren’t always in the same room, much less on the same continent. And we couldn’t be happier about it. We ship code quickly, without a lot of red tape, and still maintain an incredibly high level of code quality. It’s a great way to keep your developers happy, and we think it can work in your company, too.

Big companies can create really big software disasters. Some of the worst commercial failures have come from undersized production systems. Millions of dollars get thrown into hardware at the last minute. Just moving to the cloud doesn’t help. It lets you get the (virtual) hardware in place faster, but you still might spend a lot more than you expect for capacity. This session will present a technique for analyzing your system’s capacity–either during development or as you contemplate changes. Using these techniques could save you a lot of embarrassing downtime and your company a lot of money.

In the challenge to reach the lowest possible latencies, as we push the boundaries of transaction processing, the good old fashioned lock imposes too much contention on our algorithms. This contention results in unpredictable latencies when we context switch into the kernel, and in addition limits throughput as Little’s law kicks in. Lock-free and wait-free algorithms can come to the rescue by side-stepping the issues of locks, and when done well can even avoid contention all together. However, lock-free techniques are not for the faint hearted. Programming with locks is hard. Programming using lock-free techniques is often considered the realm occupied only by technical wizards. This session aims to take some of the fear out of non-locking techniques. Make no mistake this is not a subject for beginners but if you are brave, and enjoy understanding how memory and processors really work, then this session could open your eyes with what is possible if you are willing to dedicate the time and effort in this amazing subject area. The attendees will learn the basics of how modern Intel x86_64 processors work and the memory model they implement that forms the foundations for lock-free programming. Empirical evidence will be presented to illustrate the raw throughput and potential latencies that can be achieved when using these techniques.

This presentation discusses high availability at Heroku, the cloud application platform. We motivate the discussion with specific examples from our experience designing, developing, and operating highly available cloud services at scale. We emphasize that high availability depends critically on the interaction between development and operations, and highlight several patterns that we’ve found useful in our systems work at Heroku.

In most disciplines built on skill and knowledge, from art to architecture, from creative writing to structural engineering, there is a strong emphasis on studying existing work. Exemplary pieces from past and present are examined and discussed in order to provoke thinking and learn techniques for the present and the future. Although programming is a discipline with a very large canon of existing work to draw from, the only code most programmers read is the code they maintain. They rarely look outside the code directly affecting their work. This talk examines some examples of code that are interesting because of historical significance, profound concepts, impressive technique, exemplary style or just sheer geekiness.

Most programmers’ experience with distributed consensus is either purely theoretical (“well, I read a bunch of Paxos papers”) or based entirely on specific systems (“we solve all of our consistency problems with Zookeeper”) and this has an unfortunate consequence: many production systems have behavior that is not fully understood by anyone at all. Justin will break down the barrier between theory and practice by discussing exactly what promises various real, deployed systems can make when it comes to consistency in the face of failure.

Mediocrity guaranteed. This sad tagline describes most of the processes we use today including typical agile process. It’s easy to see why. Software development’s an expensive risky business. To deal with the risk, the players involved adopt a client-vendor model where those in the client role give requirements and those in the vendor role estimate time and effort and agree to build what’s asked for. In this model we clearly separate responsibilities so that we know who’s accountable when things go wrong. Although we know things rarely go as planned, and innovative ideas rarely spring from such a relationship, we continue to work in processes where treating our coworkers as outsourced vendors is considered best practice and risking everything on the ideas of a select few isn’t regarded as risky.

This talk is about an alternative way of working.

In this talk Jeff explores companies beginning to adopt a style of working where everyone in the organization gets involved with identifying and solving problems. You’ll hear examples from real companies describing their practices for learning first-hand about customers and users, practices for collaboratively designing solutions for the problems found in the real world, and approaches to learning if what we created really benefited anyone. This new style of work is a process cocktail combining the best of agile development, lean software development and lean startup, user-centered design, and collaborative design thinking.

This style of work isn’t the traditional client-vendor model where knowing who’s to blame is the primary concern. It’s a co-making style of work where everyone brings their skills and experience to the table and together takes ownership for making great things.

Would you believe that the image below of the famous Utah Teapot is rendered using just div elements and CSS without any OpenGL, WebGL, Canvas, or other “real” graphics capabilities?

In this fun talk, we will explain this glorious hack we first learned from a blogpost by Jeff Lau aka Useless Pickles, and that we subsequently used as a demo for our IL to JavaScript compiler project.

While the original Live Labs project has long gone to the happy hunting grounds of technology, we salvaged this little pearl as a timeless demonstration of doing a lot with very little.

Software developers start on a journey when they join the industry. Slowly, they start to acquire rules of thumb and guidelines that they use to help them design software. As they go, they learn about the corners and traps that that software presents as a medium, and the limitations that make design a vibrant creative process. In this talk, Michael Feathers will describe the things that he wishes he knew about software when he start programming 25 years ago. He’ll describe how they interrelate and how we can move forward toward deeper understanding of how to approach design problems.

The Agile movement shifted the relationship between clients and developers in a profound way. In waterfall processes, clients specified large amounts of functionality, then nervously faded into the background until the fateful day-of-delivery. With Agile, developers strove to engage with clients continuously, and delivered much more frequently against their needs. A new trust was established. At the Forward Internet Group in London, we are implementing a second major shift between clients and developers. The trust of the clients in developers evolves into a broader trust of the developers to deliver business value without resorting to a series of well-defined stories. In essence, the business has empowered the developers to do what they think is right for the business. This model, popularized by Facebook, has several labels, but the one we prefer for our flavor is Programmer Anarchy.

Agile software development was born over a decade ago, with a gathering of industry luminaries in Snowbird, Utah. They were frustrated that so much ceremony and effort was going into so little success, in failed project after failed project, across the software industry. They had each enjoyed amazing successes in their own right, and realised their approaches were more similar than different, so they met to agree on a common set of principles.

Which we promptly abandoned.

The problem is that Agile calls for us to embrace uncertainty, and we are desperately uncomfortable with uncertainty. So much so that we will replace it with anything, even things we know don’t work. We really do prefer the Devil we know.

For the last couple of years Dan has been studying and talking about patterns of effective software delivery. In this talk he explains why Embracing Uncertainty is the most fundamental effectiveness pattern of all, and offers advice to help make uncertainty less scary. He is pretty sure he won’t succeed.

In four years, New Relic has grown from a dozen customers to over 25,000 customers, and from collecting hundreds of metrics a day to collecting billions a day. We’ve done this without a huge investment in hardware – which is very cool. This talk will cover some of the ways we built a system that has scaled so effectively. Sharding, of course, but sharding is not magic; caching, of course, but caching is not magic; hardware improvements, of course, but … well, you get the idea. There is no one magic solution but a combination a number of strategic decisions.

With Clojure on the rise it is time you learned how to properly wield your parens. Join Aaron as he walks you through building software with Clojure. You will walk through a real world example; building a library for working with Redis. Building beautiful abstractions on top of data has always been the lisp way, and this example will be no different. You will walk away with a better understanding of Clojure, interfacing with external services, and gain situational knowledge of when and how to use Clojure’s macros to help you produce more powerful abstractions.