Have you ever wondered how our software industry has got itself into the pickle it is currently in? Most projects end up being massively late, costing way more than expected, and delivering big balls of mud that no one truly understands and thus are a nightmare to maintain. In desperation we try out the new approaches we hear about from the analysts and press. Approaches which often have wacky names and sort of make sense, yet, when we try them we still seem to be no better at successfully delivering software than we were a few decades ago.

This talk will be a full scale rant, attacking the technology industry’s sacred cows by exposing the motivations that hide behind them. We’ll show how these motivations lead us into practices that hinder rather than help us deliver quality software, practices that often make our lives just plain miserable.

However, all is not doom and gloom. Some organisations, notably the new breed of online technology lead companies, seem to be achieving things that the traditional corporate IT departments can only dream of. What are they doing differently? We’ll finish by exploring this question and what we can all learn from it.

Have you ever wondered how our software industry has got itself into the pickle it is currently in? Most projects end up being massively late, costing way more than expected, and delivering big balls of mud that no one truly understands and thus are a nightmare to maintain. In desperation we try out the new approaches we hear about from the analysts and press. Approaches which often have wacky names and sort of make sense, yet, when we try them we still seem to be no better at successfully delivering software than we were a few decades ago.

This talk will be a full scale rant, attacking the technology industry’s sacred cows by exposing the motivations that hide behind them. We’ll show how these motivations lead us into practices that hinder rather than help us deliver quality software, practices that often make our lives just plain miserable.

However, all is not doom and gloom. Some organisations, notably the new breed of online technology lead companies, seem to be achieving things that the traditional corporate IT departments can only dream of. What are they doing differently? We’ll finish by exploring this question and what we can all learn from it.

The metrics that are commonly used for assessing software team productivity are based on outputs in the form of features, user stories or function points, and throughput measures such as story points or cycle time.

The big question is, are these the right metrics? Or are we only measuring these because they are easy?

According to one of the leading research companies, the next emerging trend is to move away from these throughout and output measures to ‘Outcome metrics’. Where throughput measures the effort over time, and outputs measure how much you deliver, outcomes measure the results achieved at the desired quality levels.

In this compelling talk, Gabrielle Benefield will discuss the pitfalls of traditional metrics and how they are not fit for purpose, then provide an alternative approach that teams are adopting worldwide using the Mobius framework.

Gabrielle will walk a case study where they used this method to save a client twelve million pounds annually, after only two days work and dramatically changed the product backlogs for the teams.

Not only can outcome metrics transform the business, they can also be used to assess the technical quality of what is being built, align the customer and suppliers to build ‘the right product’ and give suppliers a competitive edge.

Join us to hear about our adventures in a microservice world at realestate.com.au. Learn about the problems that launched our journey, the solutions to our problems, and the solutions to our solutions. We’ll share lessons that we have learned, things that have gone well and less well, where we want to go next, and some of the approaches and tools that we’ve adopted to make the approach sustainable.

The prevalence of online attacks against websites has accelerated quickly recently and the same risks continue to be exploited. However, these are often easily identified directly within the browser; it’s just a matter of understanding the vulnerable patterns to look for.

‘Hack Yourself First’ is all about developers building up cyber-offence skills and proactively seeking out security vulnerabilities in their own websites before an attacker does. It recognises that we have huge volumes of existing websites that haven’t gone through sufficient security review plus we continue to create new content that even when built with security in mind, still needs testing from the perspective of a cybercriminal.

In this session we’ll look at website security from the attacker’s perspective and exploit common risks in a vulnerable web application. We’ll also explore ways to easily grab credit cards, gain immediate FTP access to thousands of websites, crack password cryptography you think is secure and hijack wifi.

The first generation of human-computer interfaces (HCI) (1950s-70s) used punched cards and line printers as interface devices. It was considered wonderful at the time (I remember). Starting in the 1980s with the Xerox STAR and Smalltalk systems and then the Apple Macintosh, this was replaced by the WIMP (“windows, icons, menus, pointer”) graphical user interfaces that are now commonplace. We have seen another genuine revolution in computing in the last five years, brought on by the introduction of “smartphones” that incorporate able-bodied computers (in terms of MIPS and GBytes) combined with three or more radios (cell, WiFi, Bluetooth, GPS) and a variety of sensors (microphones, multi-touch screens, cameras, accelerometers, compasses, etc.). These devices are growing in popularity as “media hubs” posing as telephones or tablets.

It should be obvious that the future of computing is to be found here, that the coming generations of laptop and desktop computers will integrate I/O devices for multiple media and multiple modes of networking, and that this new generation of HCI systems will be as different from the WIMP model as it was from the punched card world that preceded it. This presentation will draw from the presenter’s 30 years of experience in advanced multimedia computing, and decade of experience teaching graduate courses in multimedia engineering at the UC Santa Barbara. It will consider a series of ancient technologies that are now relevant again as well as posing a set of questions about our assumptions about how people interact with software and services.

Far from alleging to have all the answers, the presenter will re-evaluate several assertions made in the last 30 years regarding the use of “thin” clients, of cloud computing and data storage, on the increasing use of multimedia data, and on support for higher-level data models and interaction modes in end-user application software.

Microservice architectures have generated quite a bit of hype in recent months, and practitioners across our industry have vigorously debated the definition, purpose, and effectiveness of these architectures. In this session, we’ll cut through the hype and examine some very practical considerations related to microservices and how we might solve them:

• Not an End in Themselves: why microservices are really all about continuous delivery and how they help us achieve it.
• Systems over Services: why microservices are less about the services themselves and more about the systems we can assemble using them. Boilerplate patterns for configuration, integration, and fault tolerance are keys.
• Operationalized Architecture: microservices aren’t a free lunch. You have to pay for them with strong DevOps sauce.
• It’s About the Data: bounded contexts with API’s are great until you need to ask really big questions. How do we effectively wrangle all of the data at once?

Along the way, we’ll see how open source technology efforts such as Cloud Foundry, Spring Cloud, Netflix OSS, Spring XD, and Hadoop can help us with many of these considerations.

This talk celebrates the awesome parts of the Groovy language and the Groovy ecosystem. You’ll see some exciting examples of Groovy and it’s application. Everything from domain specific languages, dynamic typing, the extensible static typing system, Android programming, concurrency, enterprise programming made productive, functional programming and a host of interesting frameworks and tools.

Microservice architectures have generated quite a bit of hype in recent months, and practitioners across our industry have vigorously debated the definition, purpose, and effectiveness of these architectures. In this session, we’ll cut through the hype and examine some very practical considerations related to microservices and how we might solve them:

• Not an End in Themselves: why microservices are really all about continuous delivery and how they help us achieve it.
• Systems over Services: why microservices are less about the services themselves and more about the systems we can assemble using them. Boilerplate patterns for configuration, integration, and fault tolerance are keys.
• Operationalized Architecture: microservices aren’t a free lunch. You have to pay for them with strong DevOps sauce.
• It’s About the Data: bounded contexts with API’s are great until you need to ask really big questions. How do we effectively wrangle all of the data at once?

Along the way, we’ll see how open source technology efforts such as Cloud Foundry, Spring Cloud, Netflix OSS, Spring XD, and Hadoop can help us with many of these considerations.

Real-time reactive user interfaces need to scale from handling dozens, and sometimes hundreds, of updates per second, to changes in data on a daily or weekly basis, as well as handling input from users. This means that literally everything is a stream of data.

We will discuss how the trading applications we’ve built make extensive use of reactive extensions to compose these streams to provide real-time, correct information about the state of the market, and the system. We’ll talk about the internal architectures of real time trading applications built to handle this sort of complexity.

Stop me if you’ve heard this one: “We used to be small. We made great decisions, got product to the market fast, and were very successful. Now we are big. And slow. Our teams don’t work together very well. Our specialists are spread too thin. Our products are less than awesome.”

Getting teams to work well is hard. Getting teams to work well together is much harder. And the dilemma is, what works in a small organization is often counterproductive at scale. The question is – what do you have to do differently when you grow up?

For starters, scaling is fundamentally a complexity problem, so you should look for ways to reduce and deal with complexity. Second, scaling is a cooperation problem, and understanding what promotes and what destroys cooperation is essential for growing organizations.

Finally, scaling is an organizational problem, and there’s no shortage of models to study for patterns of how to scale organizations. There’s the lean model, the military model, and several unicorn models. These models confirm the fact that scale is possible, and are full of ideas for you to experiment with. But they won’t tell you which approach is best for you – you have to figure that out for yourself.

It makes good sense to follow Google’s lead with technology. Not because what Google does is particularly complex – it isn’t. We follow Google for two reasons:

1. Google is operating at an unprecedented scale and every mistake they make related to scale is one we don’t have to repeat, while every good decision they make (defined as “decisions that stick”) is one we should probably evaluate;
2. Google is as strong an attractor of talent as IBM’s labs once were; that much brainpower – even if a large part of it is frittered away on the likes of Wave, Buzz and Aardvark – produces value for all of us.

Using Hadoop is not following Google’s lead. It’s following Yahoo’s lead, or more precisely, venture capitalists who took a weak idea and made an industry of it. MapReduce is behind state-of-the-art to the point that Google discarded it as a cornerstone technology years ago.

The problems of scale, speed, persistence and context are the most important design problem we’ll have to deal with during the next decade.

We must work through what we mean by “big data”, what we mean by “structured” and “unstructured” and why we need new technologies to solve some of our data problems. But “new technologies” doesn’t mean reinventing old technologies while ignoring the lessons of the past. There are reasons relational databases survived while hierarchical, document and object databases were market failures, technologies that may be poised to fail again, 20 years later.

What can following-Google, as a design principle, tell us about scale, speed, persistence and context? Perhaps that workloads are broader than a single application. That synthetic activities downstream from the point where data is recorded are as important as that initial point. Or that relational models of some sort will be in your future.

This talk with discuss Apple’s new Swift programming language for the development of iOS and Mac apps. A language overview and comparison to other popular modern languages will be provided, followed by coverage of the new data structures and functional programming abilities of the language, interoperability with other languages, and a frank discussion of the advantages and shortcomings of using Swift for future development

Real-time reactive user interfaces need to scale from handling dozens, and sometimes hundreds, of updates per second, to changes in data on a daily or weekly basis, as well as handling input from users. This means that literally everything is a stream of data.

We will discuss how the trading applications we’ve built make extensive use of reactive extensions to compose these streams to provide real-time, correct information about the state of the market, and the system. We’ll talk about the internal architectures of real time trading applications built to handle this sort of complexity.

Julia is well-designed; it’s fun to write and easy to learn, especially for its niche of technical computing. However, one of the biggest draws for new users is its speed. Julia was designed from the beginning to run fast without heroic implementation efforts. This has allowed it to achieve near-C speeds despite still having only a handful of full-time developers. I’ll talk about some of the key things Julia does to be fast, from aggressive specialization to best-effort type inference and beyond. I’ll show what fast Julia code looks like, discuss what makes specific features fast (e.g. multiple-dispatch), and put this all in context with Julia’s “low-magic” design philosophy.

In startup time, 6 years practically stretches into prehistory. Technologies come in and out of fashion, patterns become anti-patterns, frameworks are born and die (…and then there’s Javascript). But what does it mean at business scale? Let’s take a technical look at the choices and consequences in a long-running codebase, and how it changes to support a business.

We will take a tour of New Relic’s history – examining database design choices, Ruby patterns, Javascript frameworks, and supporting deprecated libraries – and emerge the other side with insight on how to best survive the past while still innovating for the future.

What do organizations do with Hadoop? What are the components in the Hadoop ecosystem used for?

This talk will take you through a story about “DataCo” and how they use various tools in the “Big Data Landscape” to address a handful of business needs that come with data challenges. DataCo might be a made up company, but the use cases exemplified and show cased in this high-level tutorial, are based on real world use cases.

At the end of this talk a set of common use cases as well as a couple of unique ones will be shared, to inspire what really is possible, when organizations start looking at what they can get out of exploring their big data space.

Web Components enable us to use HTML, CSS and JavaScript to extend the DOM with reusable components. Discover how to combine Templates, Shadow DOM, Custom Elements, and HTML Imports to semantically and accessibly expand the DOM. With Web Components, we can revolutionize the way we develop the web.

Did you know there are thousands of visual tools available to help you solve problems, innovate, and improve everything that you do? But with thousands available from many authors, how do you figure out which tools to run? And when?

Pippi’s Book of the Dead Trading Cards explains a new concept called seestringssm, visual, concatenated equations to see and solve problems.

Topics include:

What is a seestring?
How do you build a seestring?
How do you run one?
How I use seestrings in my Agile practice
This is an abbreviated version of the Seestrings Workshop, ideal for advanced Agile/Scrum team members.

For more information, Kramer: Seestrings in Black + White video: http://www.vimeo.com/111180921

Working effectively with large volumes of data presents challenging technica​l and human factors ​issues. For example, how can today’s analyst iteratively process, display and explore 10s of​ millions records in order to identify new trends or patterns. Over the last few years, we have been wrestling with some of the more pragmatic aspects of trying to build and deliver a big data analytic solution that meets the needs of the typical analyst.

In this talk, we will discuss several of the ​technical and human factor issues with making big data accessible to the data scientist or analyst. Topics covered will include what type of interactive analysis support is required for large datasets, what types of visualizations are needed for big data, what type of scripting or programming support is needed for analysts, how to address the typical analyst task flow in a big data solution and the need for non-linear task flow support. In addition, they will discuss some of the generic ways of dynamically visualizing data and the fundamental principles of good visual design for data.