For decades, formal methods have offered the promise of software that doesn’t have exploitable bugs. Until recently, however, it hasn’t been possible to verify software of sufficient complexity to be useful. Recently, that situation has changed. SeL4 is an open-source operating system microkernel efficient enough to be used in a wide range of practical applications. It has been proven to be fully functionally correct, ensuring the absence of buffer overflows, null pointer exceptions, use-after-free errors, etc., and to enforce integrity and confidentiality properties. The CompCert Verifying C Compiler maps source C programs to provably equivalent assembly language, ensuring the absence of exploitable bugs in the compiler. A number of factors have enabled this revolution in the formal methods community, including increased processor speed, better infrastructure like the Isabelle/HOL and Coq theorem provers, specialized logics for reasoning about low-level code, increasing levels of automation afforded by tactic languages and SAT/SMT solvers, and the decision to move away from trying to verify existing artifacts and instead focus on co-developing the code and the correctness proof. In this talk, I will explore the promise and limitations of current formal methods techniques for producing useful software that probably does not contain exploitable bugs. I will discuss these issues in the context of DARPA’s HACMS program, which has as its goal the creation of high-assurance software for vehicles, including quad-copters, helicopters, and automobiles.

In 2015 Java celebrates 20 years as a generally available programming language and platform. This session will cover some of the highlights, challenges, and insights gleaned of Java’s rise from newcomer to solid performer. We’ll take a look at where the technology is today, and peek into the crystal ball to explore some interesting directions that the technology may take us over the next 20 years.

Modern software developers have abandoned waterfall processes and embraced agile and lean methods. Yet, the waterfall process has left behind a dangerous legacy, one that stealthily controls our behavior. Developers act as if uncertainty is intrinsically bad, and predictability is intrinsically good. Consequently, they strive to eliminate as much variability as possible in schedule, performance, and cost. And, although they never use the term, they deeply value determinism. In this presentation, Don Reinertsen will present an alternative view. How could we design development processes such that variability improves economic outcomes rather than hurting them? When we seek to thrive in a stochastic world, rather than merely survive in it, we look at things quite differently.

What does it mean to be complicated? How can we manage complexity when we scale up systems? Why do people find it horrifying when the internal complexity of monolithic apps is replaced by a “death star” diagram of the relationships between microservices? Why do people expect complex adaptive systems to behave predictably? How does complicated relate to intuitive? Why is one of the most complicated things we own, our smartphone, easy to use by 2 year olds?

As programmers we all know about the importance of test suites but tend to leave creating a benchmark – either to measure against other software solutions, or to compare hardware choices – until the last minute. That can lead to a hardware choice made on too few criteria, having to react to a competing shiny solution on their ground, or simply continuing with your own ””new features”” when they should be taken behind the woodshed.

This can determine your work environment and team membership for years. I will discuss ways to avoid being caught out, and the importance of taking the time to prepare in advance.

Imagine you are programming right now. Let that image sink in. What are you programming?

For the past two years I’ve been writing a program that manipulates language like a poet. In doing this I am using the software as an instrument to understand how writers think. I am programming it in Common Lisp. The output of that program has been judged master-level poetry by an expert audience. In this talk I’ll tell you how my program works and how it’s programmed. I suspect the programming I do is not like the programming you do.

Haskell has recently begun seeing more production use, as tooling has improved dramatically (no more Cabal hell), and the language features are particularly well-suited to the problems challenging many organizations (i.e. concurrency and multi-core scalability). In this talk, we’ll see how Helium, a startup using Haskell, builds, deploys, monitors, tests, and writes Haskell in production.

Facebook moves fast on mobile, shipping the mobile application at least twice a month to hundreds of millions of diverse devices. We also want to make sure the application is fast, as this is a primary ingredient in a delightful user experience. This talk walks through how Facebook thinks about performance as a feature, how it measures success, and deep dives in to the tools we’ve built to improve performance, prevent regressions and enable an amazing experience for everyone.

Moving to a microservice architecture and embracing a cloud native approach is a complex challenge, which often requires re-evaluating our approach to technology. Having previously helped transition Hailo to a new microservice platform, built almost entirely in Go, Matt leverages modern technologies and a microservice based approach to build reliable platforms which can scale to millions of users. This talk will cover how to develop and migrate to a microservice based architecture using Go, common pitfalls to avoid, and lessons learnt when developing high volume, low latency, distributed applications.

We know the “right thing” to do is to work together, to remove bottlenecks, to automate, automate, automate. But when the status quo is finger-pointing, mistrust, blame, and over-exhaustion from increasingly complex manual releases, it seems impossible to find a way to climb out of the downward spiral. How did an IT department turn this around to become a harmonious department with common goals and over 10x faster cycle times?

Winning the hearts and minds needed for lasting DevOps change requires something more than just great automation. This is the story of how Wotif found a way to incentivise a DevOps transformation across an entire IT department, resulting in cycle times measured in hours instead of weeks/months. While this journey involved technology such as DropWizard, Puppet & ZooKeeper, Matt (dev) and Alexandra (ops) extract principles that they hope can be applied to any organisation at grassroots and leadership levels using existing toolchains to support not only the best ideas of the present but also the legacy of the past and the unknown innovation of the future.

C# is evolving rapidly on all fronts. Runtime, libraries and IDE support show up on new platforms. The language itself has added many smaller features recently, and we are looking at much bolder steps for the next version. The “Roslyn” language engine offers real time access to syntactic and semantic information about source code and has a public API for anyone’s static analysis tools, IDE extensions and scripting environments to freely tap into. This whole gigantic playground is open source for everyone to tinker with and contribute to. Even if you don’t play in C# in your daily life, don’t be shy: put on your curly braces and come join us in a swing!

A big challenge in building complex, data-intensive systems is how to sustainably support data variation along with schema and feature evolution. This talk examines strategies, practices, and patterns drawn from real experiences that support new and evolving data-processing requirements while keeping the core architecture clean. As complex systems evolve to meet varying data formats, they can devolve into poorly architected Big Balls of Mud filled with special-case logic and one-off processing. Alternatively, you can isolate core components of your system and protect them from entanglements and unnecessary complexity by designing them to operate on common data formats while providing extension mechanisms that enable processing variations.

The real world, with all its complexity, can at the same time be simple, elegant and beautiful. It thrives on autonomy and asynchrony, the two most important things that bring order to chaos. The real world does not pause for something to complete before moving on. And yet, when we write software, “Command and Control” is the norm. We find clever ways of doing this while keeping up with all the new technologies and the languages in fashion, all the while ignoring the realities of life.

In this session, explore an alternate universe in which Event Driven Architecture can power even the most complex mission-critical systems. Learn how communicating asynchronously via events leads to building systems that are autonomous and much more reliable. Embrace asynchrony and autonomy. Make the complex simple.

Netflix is a large and ever-changing ecosystem made up of:

• hundreds of production changes every hour,
• thousands of micro services,
• tens of thousands of instances,
• millions of concurrent customers
• billions of metrics every minute.

This is an in-the-trenches look at what operating at Netflix scale is really like. It covers how Netflix views the velocity of innovation, expected failures, high availability, engineer responsibility, and obsessing over the quality of the customer experience. It also explains why freedom and responsibility are key, trust is required, and chaos is your friend.

Even when located in one of the largest cities on the continent of Africa, we still face many challenges when building software: lack of electricity, little to no connectivity particularly in rural areas, cash-based transactions, lack of an address system, and more. But out of these constraints come creative and innovative ways to address these unique challenges … and with it some frugal software innovation you might want to hear about.

We know the “right thing” to do is to work together, to remove bottlenecks, to automate, automate, automate. But when the status quo is finger-pointing, mistrust, blame, and over-exhaustion from increasingly complex manual releases, it seems impossible to find a way to climb out of the downward spiral. How did an IT department turn this around to become a harmonious department with common goals and over 10x faster cycle times?

Winning the hearts and minds needed for lasting DevOps change requires something more than just great automation. This is the story of how Wotif found a way to incentivise a DevOps transformation across an entire IT department, resulting in cycle times measured in hours instead of weeks/months. While this journey involved technology such as DropWizard, Puppet & ZooKeeper, Matt (dev) and Alexandra (ops) extract principles that they hope can be applied to any organisation at grassroots and leadership levels using existing toolchains to support not only the best ideas of the present but also the legacy of the past and the unknown innovation of the future.

The security of containers has been a hotly discussed topic. This talk will explain the main concerns around container security, and offer some best practices and guidance for addressing them. The guiding philosophy is “defense in depth”; no one layer or tool should be relied upon to provide complete security.

The topics covered will include:

• The isolation guarantees of containers
• Using Content Trust to make sure your images haven’t been tampered with
• How to limit the resources that containers can access
• How to audit and monitor containers
• Using VMs and containers together to maximise security and efficiency
• How to safely share secrets (API keys, passwords) with containers

Modern software can only be built in terms of existing software. The roots of programs we use every day stretch back to the earliest days of computing. Like all infrastructure, the value of this shared structure as a supply chain, and as a conceptual framework, is tremendous. Facebook explicitly takes advantage of these economies by employing “The Hacker Way,” which favors quick, loosely coupled iterations based on existing solutions, over extensive planning and coordination. We have demonstrated that this is a remarkably effective way to develop and improve our products.

At the same time, the requirements for our software products change more quickly than our software environments. Mismatches between product features and the infrastructure we build them on gives rise to bloat and inefficiency in our applications over the long-term. Facebook’s product infrastructure is intended to plug these gaps in order to help product teams to move faster, without sacrificing too much in efficiency or performance.

The most recent shift from a golden age of web-delivered desktop software, to the brave new world of mobile development, has widened many of these gaps, creating room for Facebook projects like React Native, GraphQL and Relay to deliver significant value. This talk will explore some general ideas about how we develop product infrastructure at Facebook, and also how these specific technologies fit together and what that implies about the next generation of mobile infrastructure.