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?

On August 5th 2012, NASA landed its most capable robotic geologist on the surface of the Red Planet. The Mars Science Laboratory (MSL) mission landed a 2000lb rover, the size of a compact car, to explore the planes of Mars. The rover, aptly named Curiosity, will search for organic compounds, characterize the climate and geology, and continue the search for life. One of the most challenging aspects of the mission, from an engineering perspective, was safely landing the rover on the surface. The entry descent and landing (EDL) system used a heat shield to accommodate its hypersonic entry conditions, followed by a supersonic parachute, and eight retro rockets for the powered descent phase. For its final terminal descent, a maneuver called the sky crane was used where the rover was lowered on tethers for touchdown. The talk will describe the motivation for Mars Exploration and how the MSL EDL engineering challenges were tackled with computational modeling and cutting edge experimental techniques.

On August 5th 2012, NASA landed its most capable robotic geologist on the surface of the Red Planet. The Mars Science Laboratory (MSL) mission landed a 2000lb rover, the size of a compact car, to explore the planes of Mars. The rover, aptly named Curiosity, will search for organic compounds, characterize the climate and geology, and continue the search for life. One of the most challenging aspects of the mission, from an engineering perspective, was safely landing the rover on the surface. The entry descent and landing (EDL) system used a heat shield to accommodate its hypersonic entry conditions, followed by a supersonic parachute, and eight retro rockets for the powered descent phase. For its final terminal descent, a maneuver called the sky crane was used where the rover was lowered on tethers for touchdown. The talk will describe the motivation for Mars Exploration and how the MSL EDL engineering challenges were tackled with computational modeling and cutting edge experimental techniques.

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.

Say you have started a book club. You need to coordinate with the members to choose books to read, schedule meetings, decide who is bringing the wine and cheese, etc. You probably use some spreadsheets, some web services like message forums and polls — and make it all work with a flood of email. You watch your life passing by as you robotically copy and paste between email and spreadsheets and all these services. What you want is a custom website like a Rails app or a Drupal installation, but you were an English major. What you need is a tool as easy to learn as a spreadsheet or HyperCard, but one designed to build ad-hoc social applications. Of course it should be at home on the dominant platform for social software: phones.

Transcript takes the vision of end-user programming as in HyperCard and reimagines it on the phone, designed to do the things you want to do with a phone: mediate and structure conversations. The experience is more like editing a document than programming, but hidden inside this Trojan Horse is a highly distilled yet fully capable programming language. I will demo an early prototype of Transcript and discuss our vision of bringing programming to everyone.

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.