The one-day IT conference Beauty in Code is back again with an interesting mix of stars from near and far!

Register Now


08:30 - 16:00
March 2, 2019



The Beauty in Code conference is back!

Welcome to an inspiring day at Malmö Live! We have gathered some amazing speakers that are bringing new exciting material that hasn't been presented before. Beauty in Code is a single-track conference featuring six different speakers from three continents.

This is a conference for everyone involved in the software industry. We are looking forward to see you at Malmö Live on March 2!

Spread the word, the registration is open!

Limited number of seats!

See you there!

08:15 - 09:00
Image description

The doors open


09:00 - 09:45
Image description

1. Session — Linda Rising

Thinking Fast and Slow

When Daniel Kahneman won the Nobel Prize for developing a new model of how the brain works, it changed how we think about thinking. If you haven't had time to read Kahneman's book "Thinking Fast and Slow," or even if you have, Linda will "translate" the model and what it means for us in working better. We know that our jobs involve thinking, problem-solving, and decision-making. We all want to do a better job of thinking fast and slow. Linda will help you get started with that.

09:45 - 10:15
Image description



10:15 - 11:00
Image description

2. Session — Kjell Ljøstad

How to become Agile without Scrum or Kanban

This is NOT a talk about Scrum or Kanban. The Agile Manifesto is all about communication, interaction, collaboration and building trust. Yet when most companies decide to go agile, they focus on implementing some rigid process that they don't yet fully understand, and they have a hard time getting it to work. We go back to the core of the Agile ideology. We will talk about how you can use relational skills to improve communication, get team members engaged and build trust.

Agile initiatives tend to become a matter limited to the developers, and it is often hard to engage other parts of the organisation. In this workshop you will learn what make teams work efficiently and the basics of how you can get the whole organisation to cooperate better. By building relations and trust between people, working on how they communicate and how they interact with each other, you will build the foundation of a truly agile organisation.

11:15 - 12:00
Image description

3. Session — Kevlin Henney

What Do You Mean?

"It's just semantics." How many conversations about philosophy, politics and programming are derailed by this thought-stopping comment? Semantics is all about meaning. If there is one thing we struggle with and need to get better at, it is the search for and clarification of meaning. The world in which a software system lives is filled with meaning. The structure, concepts and names that inform the code, its changes and the mental models held by developers are expressions of meaning. The very act of development is an exercise in meaning — its discovery, its formulation, its communication. Paradigms, processes and practices are anchored in different ways of thinking about and arriving at meaning. But just because we are immersed in concepts of meaning from an early age, and just because the daily work of software development is about wrangling meaning, and just because it's just semantics, that doesn't mean we're necessarily good at it. It takes effort and insight. Let's talk about what we mean.

12:00 - 13:00
Image description



13:00 - 13:45
Image description

4. Session — Jon Skeet

Sondheim, Seurat and Software: finding art in code

White. A blank page or canvas. The challenge: bring order to the whole. Through design. Composition. Tension. Balance. Light. And harmony. The opening lines of Sondheim's "Sunday in the Park with George" were written with fine art and paintings in mind, but ring true for software engineer as well.

As Seurat created grand visions from tiny dots, so software solves huge problems one line at a time. Some parallels are obvious - the suggestion of "favor composition over inheritance springs to mind" - but others take more reflection. This talk offers musings on each element, and links each back to the cornerstone so often neglected in the midst of design docs, specifications and linters: our shared humanity. What turns "good" code into "great" code? How subjective is this? How does it affect how libraries connect with their consumers, and how applications connect with their users? At the end of this talk, you'll be left with more questions than answers - catalysts for your own thoughts on the nature of code and art, and for further discussion.

14:00 - 14:45
Image description

5. Session — Nyari Samushonga

A seat at the table

Technology is taking an increasingly central role in the structure and reach of businesses. From its less prominent past as a rarely-noticeable cost centre buried in basements and maligned by those skeptical of its value contribution, the exponential increase in digital connectivity has moved it to its current position: a front-and centre disruptor, enabler and differentiator of modern day commerce. This shift cuts across all industries: regardless of the nature of your business, chances are you are in the technology business. The superpowers of digitisation have given those that build this new ecosystem a seat at almost every decision-making table as first-class citizens, adorned with all the rights and rewards that accrue to business leaders. But as we all know, with great privilege comes great responsibility. Are we, as an industry, reciprocating business' shift towards technology with a commensurate embrace of the complex learning curve we must undertake to understand the fundamentals of running a business? Do we fully understand the business contexts in which our superpowers are deployed? Beauty in code without responsibility in business is a waste.

14:45 - 15:15
Image description



15:15 - 16:00
Image description

6. Session — Dan North

BDD is not about Testing

BDD started as a way to teach TDD to programmers who kept getting hung up on the idea they were writing tests. Fast-forward a decade or so and it seems BDD scenario automation tools have invaded the world of acceptance testing like Japanese knotweed. All around I see teams harming themselves writing awkward, verbose tests using slow, cumbersome tools like Cucumber and SpecFlow, and acting as though BDD is some kind of testing approach.

Part of the problem is that once you have an automated BDD scenario and you've written the software to satisfy it, it can look seductively like a test. From there it is a short step to thinking of these scenario automation tools as testing software, and the rest is frustrating, repetitive history.

This talk explores the relationship between BDD scenarios and acceptance tests, and suggests some strategies for avoiding the pain of BDD-as-test automation.