The Lean Startup approach applies the principles and practices of lean manufacturing to starting a new (potentially high growth) business, or more correctly, to the process of searching for one. Although it is often misunderstood, this approach changes significantly what startups should do to achieve success. Interestingly, it has significant implications for software developers and other product developers working in startups. This presentation and discussion will consider some of the key principles and practices behind Lean Startup and point out what it means for software developers working in startups. It is highly recommended for those working as a software developer in a startup, considering doing their own startup, or are just interested in learning about this new approach and what it means for software development. Even if you think you know about Lean Startup come along, you may be surprised.

A talk similar to this has been presented for entrepreneurs and innovators previously in Perth and London and exceptionally well received. This one is tailored especially for developers and focuses on what they really need to know about Lean Startup. It will (with out a doubt) significantly change their perspective on their role as a developer in a Lean Startup. The presenter is the organiser of the Lean Startup Perth Meetup, which is a group of startup founders (many of them technical founders) who meet regularly to investigate and put into practice Lean Startup principles and practices. The presenter is also an active developer and startup founder building a system (with others) that uses Scala and Akka for microservices on the backend, with a CQRS architecture for most of the microservies, and React / Javascript on the front-end.

Relational databases are the product of decades of research and optimisation, but when your business grows so big that a database reaches breaking point, where can you turn? On the other side of the fence are a variety of noSQL databases which sell on scalability and cheaper hardware but come with their own set of issues around schemas, atomicity and consistency.

Since most developers are more familiar with relational databases, in this talk I’ll focus more on a couple of NoSQL options and how they work rather than how to use them. The fun parts are how eventual-consistency is maintained at scale and how they avoid single points of failure and bottlenecks.

In the last section, I’ll go into depth on Google’s Spanner database, which is only just recently available for public use. This follows on well from the NoSQL implementation since it was developed as a direct response to the problems of noSQL storage. Through some cool innovations, Spanner manages to achieve both global consistency and scalability.

The Internet of Things (IoT) has recently been somewhat of a laughing stock, with poorly designed and managed IoT devices being associated with severe privacy leaks, theft of service, and botnet-perpetrated denial-of-service attacks. The currently circulating joke goes “The S in IoT stands for Security!”

This presentation covers how to recognise and avoid risks to your business from adopting IoT, some best practices for selecting and deploying IoT devices, and most importantly, for developers of IoT products, how to avoid repeating the mistakes of the past, through good architecture, quality processes and use of the right tools and frameworks. I will talk about ways to ensure that less-secure or rogue devices cannot damage your network or the Internet at large, how to monitor and control your IoT devices to keep them safe and functional, and how to choose among the growing collection of incompatible frameworks for IoT systems.

IoT is the Wild West – Criminals have outrun the Law, but the Law, and good development practices, are catching up. My presentation will teach you about the guidelines, traps, tools and frameworks that you need to know about to avoid becoming the next “IoT is…” joke.

There are always ways to improve processes and standards in large organizations.

If your company or you are working on multiple and/or large JavaScript projects then you should try Jest.

This talk is about JavaScript unit testing. I’ll show the testing platform called Jest. Will tell why and how large companies can benefit from it.

The presentation is going to be fun and entertaining.

This presentation will challenge a common movement that is sweeping the lands unnoticed. Agile micro-service projects that live in a single VCS repository, that are slow to test, hard to understand need to be deployed and versioned as a single unit. While that sounds silly, ask these questions of your project:

• Are you using a layered architecture?
• Do you generally have an interface for each class (Java/.NET)?
• Do your Views live in one folder and your ViewModels in another?
• Has your platform’s package manager made it too easy to just add, more?
• Has your team mistaken “reuse” as a goal, not an outcome?
• Does your team favor living code over doco, yet no one understands how the system works?
• Could you make a one line code change, test it, commit it, package it and deploy it in under 15min?
• Do you think you are doing Microservices, but all the code lives in the same repo? Share the same contracts? Get versioned and deployed together? Share a data store?

Even if you are not on the Microservices band wagon, will your framework of choice be relevant in 5 years? Can your team pivot to new libraries, GUI or data store technologies in days or weeks? Or, are you actively building the next legacy project churn-and-burn style?

This session will pose some challenges to prevailing convention and ask how did we get here. More importantly we will discover the costs of our decisions and how we start applying an engineering instead of religious approach to design.

An introduction to serverless cloud computing via the Serverless framework running on AWS with a simple continuous integration pipeline. The aim of the talk is to 1) build a simple but working and deployed service 2) break that barrier to entry into the world of serverless and 3) get the audience moving forward with the low cost, highly scalable, agile development that can be achieved with a serverless approach.

Reactive programming can be a difficult concept to grok. Even once a you have an understanding of the basic principles it can be difficult to see how to use this technique in a real world context.

This presentation will attempt to bridge the divide between conceptual understanding and day to day usage. Through the use of (redacted) code examples from production code, I will illustrate how reactive techniques can be used. Also I will make a case for why these patterns should be adopted.

While these code example are from a swift app running on iOS (using RxSwift and ReactiveCocoa) these concepts are relevant to Reactive programming in any language.

“Style guide” is an umbrella term for several types of design documentation; static style or visual identity guides, voice and tone, front-end code guidelines or component/pattern libraries. These all offer something different but often have something in common. They look ugly enough to have been designed by someone who enjoys configuring a router.

In this fast-paced talk, Andy will demonstrate ways to improve how style guides look and make them better at communicating design information to creatives without it getting in the way of what technical people need.

You think you know TypeScript? Unless you have been looking at it recently you likely have missed some of the amazing features shipped in 2.0, 2.1 and 2.2. Some of these language features exist in very few other languages and open up so many doors.

In this talk Jake will introduce you to TypeScript and run through a number of the latest language features including spread/rest operators which many Babel users love, Mapped Types, Generics and cover practical examples where he has been using these features to improve the code he is writing day to day.

Hike is a mobile-first, messaging platform that is used by 100 million users to exchange 40 billion messages/month. Hike app is available on Android, iOS and Windows phone. On the back-end, we’ve 100+ macro-services in Java, Python, Ruby, Go and Elixir. While setting up a Continuous Delivery pipeline, we ran into a series of technical challenges. However it was more important to address the organisational/behavioural challenges to ensure a sustainable culture shift in the company.

In this talk, I’ll explain how we went about:

• Setup a trunk-based development model
• Decentralised our build & test environments using Docker and Jenkins
• Segregated and containerised our macro-services
• Refactored the mobile apps to be more container friendly
• Setup a mobile device farm using STF
• Improved the quality of code-reviews using PRBuilder & PRRiskAdvisor
• Created different kinds of automated tests to align with our CI Pipeline and get rapid feedback
• Finally how we used C3 to visualise the health of our code-base

Agile has become the industry standard for software development. However, there is one problematic subject – Creativity. It’s hard to measure the value of aesthetic, sentimental features based on time, budget and impact. The subject of this talk is on improving the creative process. Also, there will be small tips that cover tools, management, and graphic design as well.

Here are three topics to support the main idea:

1. Tools: Software / Libraries that can polish your product faster.
2. Collaborative design: How management, developers and other parts of the team can collaborate without design skills.
3. Pure visual design: How can a designer boost up their artistic skills for the maximum product value.

I found a way to ‘cheat’ the CAP theorem, and in this session, I’ll show you how to do it. No, seriously

The CAP theorem is a very difficult problem to solve in distributed systems, but it turns out that there are a few simple rules that you can follow to get strong eventual consistency in the cloud. These rules can work in almost any programming language, and I’ll talk about what it take to make it all happen. At Domain, we used these principles to recover from catastrophic data failures in our clickstream events, and in this session, I’ll show you how we did it.

With CRDTs + Event Sourcing and its intrinsic immutability, there’s a mathematically provable way to ensure that all nodes in a distributed system (such as a data store, or an Akka.NET grid) get the same level of consistency without even talking to each other.

“It is not necessary to change. Survival is not mandatory.” -W. Edwards Deming

Work takes time to flow through an organization and ultimately be deployed to production where it captures value. It’s critical to reduce time-to-production. Software – for many organizations and industries – is a competitive advantage.

Organizations break their larger software ambitions into smaller, independently deployable, feature -centric batches of work – microservices. In order to reduce the round-trip between stations of work, organizations collapse or consolidate as much of them as possible and automate the rest; developers and operations beget “devops,” cloud-based services and platforms (like Cloud Foundry) automate operations work and break down the need for ITIL tickets and change management boards.

But velocity, for velocity’s sake, is dangerous. Microservices invite architectural complexity that few are prepared to address. In this talk, we’ll look at how high performance organizations like Ticketmaster, Alibaba, and Netflix make short work of that complexity with Spring Boot and Spring Cloud.

This is a demonstration of a code quality analysis tool that doesn’t visualise the metrics – it “audiolises” them.

The concepts of poor code having smell and colour (usually red) is commonly accepted, but what about appealing to our sense of hearing as well as eyes and nose? Aeolian is an open source tool (written by the author) that generates MIDI music from code quality metrics, which begs the question:

• What does poor quality code sound like? Justin Beiber’s latest? A Phillip Glass soundtrack? A Phil Spector wall of sound cacophony? Modern Jazz?
• Likewise, what does good quality code sound like? Mozart? White noise?
• How do commonly accepted musical concepts (keys, tempo, verse, chorus) apply when illustrating code quality.

The author (an amateur musician and long time producer of smelly code) will talk through the concepts of Aeolian and provide plenty of examples of how you can map code quality to music. This will be a light hearted talk and no knowledge of music theory is needed.

Communication is difficult. Whether between humans, machines, or a combination of the two, trying to translate meaningful information is a lossy process.

Converting programming languages to use the new Unicode standard is hard, but once it’s in place, you get this marvellous feature-add: emoji compatibility. No longer do we have to make faces with symbols or use platform-specific emoticons. Rejoice in the extended character set.

Emoji have a rich history as a way to allow the communication of ideas in a reduced amount of data. They date back to a time where this was important: SMS communications in Japan. However, as social networks feverishly try to clamber onto this bandwagon, their implementations of the standard create issues with miscommunication that aren’t possible with a 12×12 pictograph.

We’ll discuss the history of emoji, cross-platform adoption, the Unicode standard, and emoji accessibility in web applications.

Often as technologists we are carried away by the various ways of problem solving, that we forget about the presentation of the solution to the required people, in an accessible way. It is easy to overlook the fact that even the best application cannot deliver value if its inaccessible to the users. This talk is about:

Accessibility and why we need it. Some good practices while developing application Emphasise the intention of accessibility as opposed to crossing a threshold set by a tool.

At Pushpay in New Zealand, we make changes to our production servers half-a-dozen times a day or more. We do this with an expanding engineering team in an industry (mobile payments) that demands rigour and risk aversion.

Join me as I talk about how we ship a feature all the way from a thought in someone’s head to running on the production servers. Sometimes, on the same day!

This session will cover the tools and systems that make this possible, but more importantly the organisational culture that is the bedrock on which those systems are implemented.

As developers, we’re constantly learning: whether it’s figuring out how to solve new problems and bugs, or focusing on new skills and knowledge to apply to our work. Often when we talk about reflecting and refactoring, it will be about the way we work in our teams or how we can make our code better – but why don’t we apply the same method to ourselves?

This talk looks at how to constantly reflect and refactor your own skills and values, creating your own idea of a “good” developer. It will examine the psychology of creating new habits, the different motivations of why we are developers, and how we can each define the type of developers we want to be.

Mars is the next destination for humans to explore and colonize in our journey through the solar system and beyond. For the past thirty years, the space programs of many nations have been sending landed platforms of increasing complexity, revealing the Red Planet’s ancient past. One of the most challenging aspects of all missions to Mars is the safe landing on the surface, from an initial entry speed of 30,000 miles per hour to a soft touchdown. During the descent to the surface, robots and eventually people are protected from extreme temperatures and G-forces by complex engineered systems. On the surface they must be able to survive radiation and low pressures, with only the limited resources they can bring with them. This talk will discuss the motivation for Mars exploration and how engineering challenges are tackled with computational modeling, cutting-edge technologies, and out-of-the-box thinking. Engineering the Red Planet is the key to our future and understanding our past.

CSS, that’s the Cascading Style Sheets variety, are accused of many issues, but none more so than their flexibility and power. What should be the factors that are the hallmarks of the CSS arsenal have become the main weapons the language’s enemies return to at any confrontation.

But rather than retreat from battle, let’s take the war to the enemy. Let’s adopt the clarity, reasoning, polymorphism, and statelessness that CSS’ enemies rally behind. We’ll learn to look at specificity, selectors, mixins, and even variables and discuss them in ways that can be seen as functional, and not merely fluid.

While immutability might not be an ally, we can certainly call on camouflage, subterfuge, and subtlety to win over our opponents.

AI and mobile are are great combination. Over the past few years we seen an explosion of AI related mobile technology: Siri, Google now, Image and voice recognition. We will conduct a high level, broad overview of the AI field, looking at some of the recent breakthroughs on mobile and the technologies behind them. We will also look at the Google TensorFlow library in more detail explaining what it is exploring some of the models that have been built using TensorFlow. Finally we will look at how TensorFlow can be used to enhance your own mobile apps, providing examples of both running TensorFlow directly on a mobile and on a server to provide a web services. This will include a live demo of my phone using TensorFlow to recognise a banana!

Over the past few years James Stewart went on an unusual journey, from a very hands-on software delivery role changing how the UK government made its website, to a high-profile position working across government to reform technology and security policy. He’ll share some of that story and some of the lessons learned along the way, with some thoughts on how as technologists we can communicate the wider changes we know are possible.

There’s no such thing as the perfect programming language. I’m sorry, but there isn’t, and I’ll explain why.

On the other hand, if you were set the task of designing the perfect language, how close could you get, how would you go about it, and what would it look like in the end? We’re going to explore this problem space with a tour along the bleeding edge of modern language design, giving you some insight into what’s already out there, what tradeoffs each new idea comes with, and what sort of tools you might be working with in a future where programming is slightly less awful than it is today.

Its increasingly common that teams are distributed across multiple offices, in different countries, all working on the same product or project. But how do you make this work well? There seem to be a number of readily accepted tenants of conventional wisdom to help deal with leading distributed teams, from seeming good ideas “teams must be co-located” to ones that are purely economic “offshore teams can be run at a far lower cost”.

This talk will challenge the conventional wisdom around leading distributed teams. I will explore how I have structured distributed teams at finder.com, and explain where and why I deviate from conventional practices (teams are not co-located or bounded by geography for instance). I will show how ignoring or modifying these can produce much better outcomes, happier, more productive teams, and a great culture of distributed work.

I have over 10 years experience leading geographically dispersed teams (in the US, Australia, Manila, and Europe) and growing successful high performing tech teams. I recently set up teams in the Philippines and Poland and will be drawing on that experience for this talk.

Leaving Your Legacy is a presentation about how to take a product-driven approach to dealing with legacy code. The talk explores the need for a product-driven approach (rather than a purely engineering approach) as a key strategy for dealing with legacy issues, the cost of re-engineering without a product-driven approach, the cost of keeping legacy product features you’re hesitant to remove, how to decide what to remove, some examples of ways to remove product features.

If a codebase reflects a product’s history, legacy code often represents legacy features. Those features in turn represent legacy notions about the product itself. It becomes clear that to solve the legacy code problem you have to examine if legacy features fit your evolving understanding of your product. The aim of course is to be able to delete all that legacy code, by removing legacy features, allowing you to focus engineering efforts where they’ll contribute the most to the development of the product.

Envato runs a suite of web marketplaces for digital goods at serious scale. Our core Ruby on Rails application is over 10 years old. This codebase has served us well, however its size, complexity and monolithic nature has made it increasingly difficult to move and improve at the pace that we would like.

In early 2016, Envato reorganised so that our communication structure was more closely aligned with the system structure that we wanted. In other words we deliberately set Conway’s Law against our monolith.

In this talk I will explore the reasons for the change, the way we went about changing, and see what progress has been made towards the goal.

HTTP2 is here to solve all our performance woes. Well, not quite, even on websites that enable it, a significant proportion of traffic uses the older, slower protocol. It’s our job as web developers to account for both.

Everything just got a whole lot more complicated.

Discover some of the techniques available to developers during this transitional period, the new catches in HTTP2 and – importantly – how to keep your visitors from giving up before your site even loads.