GOTO COPENHAGEN 2017

As human-machine interfaces become more prevalent in both home and work arenas, and our interactions with technology become more relational and conversational, it is imperative that we create machines that have a deep understanding of the user's intent. Emotions, through audio and visual cues, can enhance that understanding and lead to more relevant and personalized interactions. Emotion AI -- the intersection of human emotion analysis and artificial intelligence -- can provide the necessary information for machines to both learn and process these cues. The result transforms our interactions with apps and digital experience from clinical ones to empathetic ones. This is the promise of Emotion AI: machines that can learn, anticipate, and react to our emotions. It’s a technology that not only changes the way our devices see us, but how we see them.

The rate of business change is accelerating. Organisations must learn to build the right things better and faster to survive. Continuous delivery and lean product management help deliver “better and faster”. But we need practices to ensure the “right things” flow into these processes. Practices that help experiment and innovate with new business models, products and services before technical solutions are commissioned. This need presents technology departments an opportunity to increase their contribution towards organisational agility. Partnering with business to implement such practices and ensure diverse, cross-functional participation is crucial to ensure building the “right things”. One approach is to introduce GV design sprints into the demand process. Design sprints are a mix of business strategy, innovation, behaviour science and design thinking.

I have given several presentations about the use of stories instead of science in our industry, so I thought I should try to be more helpful and give a session on experiments. No, this is not too rigorous! I am not going to talk about statistics! I am going to talk about cheap, easy experiments, what to do, what to be aware of, including our cognitive biases. I share some of my experiences with teams who are really doing it. My goal is to encourage everyone to be a bit more methodical in decision-making and to replace "that won't work" with "how can we test it." I hope that participants will walk out the door with a plan in hand for one or more experiments to run in their workplace. I also hope to improve the scientific vocabulary a bit and describe some cognitive biases that get in the way of decision-making.

Mixed Reality is not a "one-size-fits-all" solution. The best user experiences: Emphasize the strengths and unique story of the IP Leverage not only the latest technology, but more importantly the right technology Are designed to be contextual to location or the intended physical environment Jason Yim, President and Executive Creative Director of Trigger has led over 90,000 hours of Mixed Reality Development and will walk through his design approach and reference case studies from projects like: Star Wars, Spider-man Homecoming, Honda, LEGO and The Walking Dead.

When deciding to infuse existing products with machine-learning smarts, or building ML-first products, there are multiple challenges to be aware of. First, you and your organization need to understand important dimensions -- accuracy, cost, maintainability, interpretability -- and trade-offs between them. Second, several technical challenges present themselves when deploying data science experiments into production environments. I will share some lessons learned while building ML products serving billions of predictions to live customers -- and hopefully provide some take-aways for anyone in the audience looking to indeed put machine learning into production.

In a world where deep learning and other massively scalable perception machines are at our disposal, allowing us to build amazing applications, the time is now ripe to move beyond the concept of pure perception and into broader Artificial Intelligence (AI). The path towards AI goes through what's missing in many applications today; Inference. Only when we combine Inference machines and Perception machines can we truly talk about AI. The benefit will be a machine that knows what to expect before observing it's environment and that can take prior information into account. With ever more mature Probabilistic programming languages available, we can express this marriage of perception and inference. In this talk we will scrape the surface of how to build Bayesian predictive inference machines using Probabilistic programming.

Created for developers, by developers, GOTO Conferences are focused on bringing the best minds in the software community and the most interesting topics to light

All teams go through several lifecycle phases, whether in a startup or an established enterprise. This talk should help you identify which phase of growth lifecycle your team is in and how being aware of it can help you build the right culture, make effective technology choices, hire people who will thrive in your current and next phases of growth so that you are setup to succeed well into the future. I will draw on my experience working in finance, startups, large tech, to highlight various phases going from a startup to an enterprise and chalking that path from a single application with a single datastore to a suite of applications and datastores. I will talk about culture, team structure, recruiting and present ways to hire, train, and retain the best talent and leadership required to build the best startups and modern enterprises with thoughtful software engineering principles.

Stress and stress-induced depression hit many knowledge workers, and yet it is still a taboo. “I am stressed” has become something we hear every day, and it has almost become prestigious to say so; it shows that we are busy, important people. On the other hand, it is a bit embarrassing to be really stressed and not being able to handle it. The sad thing is that when it comes to the people, who are really stressed, we don’t hear it. We do not see it; we do not talk about it. We feel awkward when people are stressed or come back from sick leave. We try not to talk about it. It is so much easier with a broken leg; we can carry stuff for them, hold the door, get coffee etc., but what do we do with a person with stress? I have been sick with stress and it took nine months to come back. It was the second time and it had to hit me hard before I took it seriously. I believe strongly in taking openly about stress and depression.

From mentoring team members to aligning engineering efforts with business priorities, today's companies are in dire need of great technical leaders. There is no management school for this and most organizations lack access to guidance or a mentorship framework that can transition their most talented core contributors into contemporary engineering managers. This talk will share tactics for using an engineer's natural pattern-matching skills within a framework for dealing with the situationally complex problems that arise within growing modern technical teams.

This session will consist of two lightning talks: Phil Winder: The Meaning of (Artificial) Intelligence The Hitchhiker's Guide says the meaning of life is 42. Considering that the field of Data Science is going through a period of exponential growth it too could soon find that the meaning of an artificial life is also 42. But if you are not involved on a day-to-day basis, the expansion can seem bewildering. The story of how disparate disciplines have combined to produce Data Science is fascinating. In this talk, we will walk through a journey of scientific discovery. Following how, from humble beginnings, a multitude of sciences (and a surprising number of hacks) converged into the incredible advancements that you see in the media today. With these building blocks, we will be able to succinctly describe what these disciplines are and how they relate. The result will be the decomposition of a "rockstar" data science application; you will see that it is not so complicated after all.

Should practitioners follow computer science research? Surely there’s enough to learn and keep up to date with without bothering about things that may be several years out? For the last 3 years Adrian Colyer has been reading a computer science research paper every weekday, and writing a summary on his blog, 'The Morning Paper'. In this talk, he’ll make the case that following CS research can be a highly rewarding, and highly relevant activity, mostly by letting a selection of papers themselves do the talking!

In my experience, there are some skills that are hard to learn as a professional programmer. You learn a lot on the job, via trial and error, and coaching from your peers. Occasionally you go on a training course and learn the basics of a new framework or language. Neither of those ways is particularly effective when it comes to a skill like Test Driven Development. There are several reasons for this. It’s hard to change the habits of a whole career in a two day class. Then when you get back to work you discover your system is not designed with testability in mind, and adding tests later is really difficult. Alternatively you may find yourself working on some kind of greenfield development where it should be easier. The trouble is you find writing tests slows you down so much, you have to abandon them as deadlines loom. In the best case, adding tests afterwards becomes the norm, and in the worst case they are not written at all.

We are doing agile, but we don’t do testing above unit test within the sprints” Or “we are doing agile, but we have something we call a hardening sprint in the end, which in our case is more of a system/system integration test phase”, or maybe “We are doing agile but we have a separate test team” - Does that sound familiar to you? The core mindset of agile is to build quality in and ensure working software – the only measure of progress. But at the same time, we time and time again see agile projects suffering from: limited unit test, limited test knowledge in the team, separate test phases outside the sprint, and no automated test above unit test level. Futhermore, many projects struggle with getting the business sufficiently involved. These challenges are a risk to not just the quality in classical terms but also to the core principle of delivering software of value to the customer.

Are you designing microservices-based applications? Attend this session for a closer look at patterns and some of the common concerns that arise in the building of high-scale distributed systems solutions. Learn about designing high-scale systems, design layers and tiers, explore enabling clusters, and create autonomous layers. Review some of the operational objectives that architects and developers aim to meet when building high-scale distributed systems solutions, learn about trade-off options, and learn about comfort zones you'll have to step out of for good.

Writing and maintaining a suite acceptance tests that can give you a high level of confidence in the behaviour and configuration of your system is a complex task. In this talk Dave will describe approaches to acceptance testing that allow teams to: work quickly and effectively; build excellent functional coverage for complex enterprise-scale systems; manage and maintain those tests in the face of change, and of evolution in both the codebase and the understanding of the business problem. This talk will answer the following questions, and more: How do you fail fast? How do you make your testing scalable? How do you isolate test cases from one-another? How do you maintain a working body of tests when you radically change the interface to your system?

Everyone is talking about Microservices and there is more confusion than ever about what the promise of Microservices really means—and how to deliver on it. To address this situation, we will explore Microservices from first principles—distilling their essence and putting them in their true context: Distributed Systems. Distributed Systems is very hard and we—system developers—have been spoiled by centralized servers for too long. Slicing an existing system into various REST services and wiring them back together again with synchronous protocols and traditional enterprise tools—designed for Monolithic architectures—will set us up for failure. As if that wasn’t enough, we can’t only think about systems of Microservices. In order to make each Microservice scalable and resilient in and of itself, we have to design each Microservice as a Distributed System—a «Microsystem»—architected from the ground up using the Reactive principles and Events-first Domain Driven Design.

"We are already agile, now can you please automate the test process, and make our company practice Continuous Delivery”… Sounds easy right? But what about the large legacy code base that is not designed for automated tests? What if our software is not a nice collection of microservices? How do you test a complex CAD/CAM GUI? Can we shape the culture of the company to make automated testing a cool thing for 300+ developers and testers? What is the cost, and do we even know the right approach to get a return on our investment? Can we use the results to document our medical software? These and more questions will be answered truthfully in this description of 3Shape’s transition towards automated tests in our build pipeline. The results of our pilot project, the strategy for rolling out to entire R&D department, the tools we used, and what did and did not work.

Mob Programming is a development practice where the whole team works on the same thing, at the same time, in the same space, and on the same computer. It is a whole-team approach to doing all the work the team does including designing, coding, testing, and working with the customers, users and other stakeholders. This is an evolutionary step beyond pair programming and accentuates face-to-face communication, team alignment, collaboration, and self-organizing team concepts of the Agile approach to software development. Mob Programming can be a highly effective approach to software development. There are numerous teams doing Mob Programming all over the world, including distributed teams, and there have been a number of positive reports of success. Please join me as I share how the concept got started, the benefits, techniques we use, and some of the problems we've faced.

Scaled Agile Framework (SAFe) is able to coordinate the work of hundreds of agile teams. But can it also be useful on a smaller, more common scale or will it just slow things down ? In this talk we will tell you about our journey from waterfall to agile for our small group of 4 distributed teams. 11 months ago we decided to try out SAFe to build a product to support staff in a large and complex enterprise with over 600 It systems and 1000+ distributed developers. We will tell you about our experiences, how we adapted, reflect on what we got right and what we have learned along the way. We might even tell you what advice we wish we would have taken and why the company CEO and users started asking questions about the teams after 3 months.

Velocity gives us motion in one direction. We want to work faster -- and more, we want to do the most useful work. We need acceleration: deliberate changes in speed and direction. How? The same way we accelerate our customers' work: automation! We already automate our work: from CI to our favorite editors to command-line aliases, we smooth our workflow. We can take this farther -- but should we? Where is the balance between racing forward, and tweaking our racecar? To achieve this, first look closely at our own work. A few observations give us data on what's really slowing us down. It may not be the technical debt you think it is: what hurts us is different from what we dislike. Next consider automation: it changes more than our speed. Jessica suggests more powerful justifications, up to generating contributions larger than our own productivity.

The case study is related to our E-commerce Web/Mobile Web Experience. We are in process of modernizing our website so we can be more nimble, and now we are working to organize the UX/Product/Tech team to ensure we can deliver delightful customer-focused experiences. We started with our product page, navigation experiences, and our mobile web experience. When we began the transformation— I noticed that there were a number of large scale heavy process experiences that do not necessarily return on investment, nor do they delight and excite the customer. We had to make a shift to developing a lean approach to delivering software fast that exceeded the expectation of our customers. We created a set of squads across all disciplines—UX/Product/Tech leadership and began the journey by starting with the customer problem and interacting with our customers much more frequently than before.

In his Lean Design Thinking talk, Michael McKay discusses how organisations and companies can utilise the new Lean UX methods to innovate and internalise actual user research in practical ways The speech defines the premise of design thinking as a shared thinking tool that links design, business and technology strategic work together around a user experience core. This is done through video documentation of actual projects with engaging interviews of participants and customers. A case story is presented in which participants from a global Fintech company visit India to develop new products for this market using a novel 5 day sprint format. The talk finally addresses the three pillars of user experience innovation culture that companies and organisations use to incorporate the new design culture, giving advice and examples of how it is done in mid to large size corporations in Silicon Valley and elsewhere.

When I started in IT the roles were clearly separated. Business Analysts wrote requirements, Architects designed them, Programmers wrote the code, Testers tested the software. Over the last decade or so we have seen a shift towards “generalising specialists” who can cut code, understand a business domain, design a user interface, participate in and automate some of the testing and deployment activities, and who are sometimes even responsible for the health and wellbeing of their own systems in production. To succeed in this new world requires more than “3 years of Java.” The modern developer needs to be constantly reinventing themselves, learning, and helping others to do the same. In this session, Dan explores some of the skills and characteristics of the modern developer, and suggests some ways you can grow them for yourself.

What are the characteristics of a good software engineer? It’s a topic many people would argue endlessly about. This is not surprising given we are effectively living in the era of software alchemy. Some of the best programmers draw on a strong scientific and engineering background. They combine this with craft like coding skills in a virtuous feedback cycle. In this talk we look back at the history of Software Engineering then explore the individual practices and techniques that can help bring out the engineer in you.

Object-oriented architects and developers have, over the years, learned many hard lessons about successfully designing systems with object-oriented programming. This has led to a plethora of 'best practices' that are painfully passed on from older to younger generations via books, lectures, consulting, blog posts, etc. Many of these 'best practices' must be explicitly taught, because they don't evolve naturally from object-oriented programming. Surprisingly, many of these hard-won 'best practices' fall naturally into place when applying functional programming. Instead of deliberate design, functional programming forms pits of success where you naturally fall into the same 'best practices' that you have to deliberately work for in object-oriented programming. In this session, you'll learn about a handful of such 'best practices', and how functional programming automatically leads you there, without your explicit effort.

There is a lot of buzz about scaling agile at the moment. One of the most popular frameworks when multiple agile teams need to collaborate is the Scaled Agile Framework (SAFe). But SAFe has also been labeled as non-agile top down command and control in disguise. What's SAFe about? What problems is it trying to solve ? And how agile is it really ? Based on practical experience from implementing agile in the enterprise, we make a comparison between a SAFe organisation and a typical project organisation implementing Scrum on team level, so you can make up your mind if SAFe might be useful or the devil in disguise.