Sponsors

Treat your Code as a Crime Scene

We’ll never be able to understand large-scale systems from a single snapshotof the code. Instead we need to understand how the code evolved and how the people who work on it are organized. We also need strategies that let us find design issues and uncover hidden dependencies between both code and people. Where do you find such strategies if not within the field of criminal psychology?
This session will reveal the wealth of information that's stored in our version-control systems. You'll learn to predict bugs, detect architectural decay and find the code that is most expensive to maintain. Along the way you'll also see how you evaluate knowledge drain in your codebase, learn the social pitfalls of team work and much more. As a bonus you'll get an introduction to both modern offender profiling and its powerful counterparts in the software world. To achieve this, the session combines research on software evolution with findings from various fields of psychology.

Legacy Code is Fear

Legacy code is fear because we fear the unknown. Learn what you need to learn in order to be less scared about legacy code during this talk.

Introduction

This will be a presentation about how you can work fast and safe with existing code. I will present the problem of working with legacy code and some of the solutions I know.

You are a programmer. Someone from the company comes with an idea to add a feature and they are sure this new feature is very easy to add. And it should be. But the code is old. The code is a mess. Nobody in the firm knows any more that part of the system. You need to change that ugly piece of code. You are afraid that you might introduce defects. Legacy code is fear.

During this talk we will discuss a Mantra Against Fear that will consist of the attitude, the tools and the techniques you can use to work fast and safe with existing code. You will learn how you can apply agile software development to messy ugly code.

Target Audience

If you are working as a programmer, tester, technical manager or CTO this talk might be extremely helpful. If you are a manager, trainer, coach you will find out about some ideas that you could implement with the companies you work with.

Process Mechanics

A very clear image of the reason to change the legacy code is essential: fix a bug, add a feature, cover the core system part with tests.

I will explain why not reading legacy code is a lot better because even if we think we are super-smart programmers we never get what legacy code really does when we read it.

One alternate way programmers could understand legacy code is to focus on writing characterization tests. But these characterization tests should be focused on a very thin layer of behavior, we should cover the least amount of code needed for the stated purpose of the change.

Characterization tests can be of several type in the beginning: System Tests, Acceptance tests, Integration tests, Component tests, Contract tests, Unit tests. But we might need to refactor some of the higher order tests, on the tests pyramid, into unit tests.

I will focus why it is essential to go in small steps that seem very unnatural to us. Also the steps may vary depending on the programming language.

Agile Software development can be applied on legacy code if we focus on delivering the value, meaning doing the change needed, and if we let all the rest of the ugly code be the same. It is a challenge for any programmer to leave ugly code behind, but changing it would not bring any value for the moment.

Usable Software Design

Whenever we talk about design in other domains than software, we discuss it from a user-centric point of view. Apple’s products are renowned because they focus on the experience of a user with their device: how it feels, how it looks, how fast it responds, the sounds it makes etc.

Software design is the only type of design that seems to be userless. After all, the end-user has no idea how the software works and doesn’t care. All they do care about is to work fine.

It turns out that software design is not userless. The user is the developer that will have to change the code after you do. So how about user-centric software design?

In this session I will show how to apply techniques from UX to software design in order to achieve: faster implementation of typical tasks and easier inclusion of new developers in the team.

Software craftsmen need to stop coding so much

Nearly every software craftsmanship event / conference I’ve attended has one theme: code.

Okay that is over simplifying it, we also talk about design, continuous delivery, pair programming and TDD. But it always comes back to the development of code and how we get it into production.

This sounds sensible doesn’t it? It is “software” craftsmanship after all, we create software with code. Code is great, talking about how to develop and design systems is an integral part of software craftsmanship. However we shouldn’t focus too much on code. Why?

Well the software we develop is becoming increasingly distributed. It involves more servers, more network hops, more data centres, well more distribution than ever before! I think most software engineers can improve them selves by focusing on fundamentals of computing rather than on code and which language to use.

How can we do this? Well let’s swap coding up fizzbuzz and start doing katas like:

• Open up a server socket on your favourite operating system
• Connect to it using a command line tool of choice and send some data
• Capture all the network traffic
• Repeat but somehow block the traffic from getting to the server side

Or how about: Write a some software that writes your name to the disk. Really? Well I mean really on the disk, not in some buffer.

Miss coding? Implement two variations of Paxos, or show how 2 phase commit doesn’t work in the case of failures by implementing it in your favourite language and killing processes.

If this sounds interesting then come and hear me rant about how we as software craftsmen need to up our game when it comes to fundamentals of computing. How if we want to evaluate which database or queueing software we are going to use we need to understand computer science e.g TCP, disks, memory and latency.

Scala in GOV.UK Digital Services

Learn how Scala and the wider Typesafe stack is used in GOV.UK Digital Services, and specifically within the DVLA. Scala has helped improve delivery time and performance of systems. See real-life examples including a Play app serving citizens and Akka for serving batch licence requests.

Common mistakes in TDD – can you guess?

Test-driven development (TDD) is an Agile practice that, used correctly, leads to better software quality and fewer defects in code. However, there are many cases where common mistakes crop up, even in teams with established TDD practices. Is TDD failing us or is it us that fail to practice in full the principles of TDD and in effect causing the problem? Join Christos Matskas as he goes through some of the most common mistakes in TDD and find out what you can do to avoid them. Laughing is optional.

Lean UX and Agile development taking the Public sector to new levels

As companies and organisations of all shapes and sizes come to grips with the fact that UX is critical to project and product success, a common question resurfaces time and again: How do we add Lean UX practices to our current Agile process?

Bringing the practice of Lean UX in to an organisation could in some cases cause apprehension. What they really want to know is, how this practice can be adopted in to their current process without having a negative impact on their output? Where companies have a mature agile process, they may be reluctant to try something new which could upset that balance. However, with experienced UX specialists, a highly collaborative team and iterative process we can show you the Lean UX techniques to ensure a better understanding of user needs.

Refactoring mount doom: the story of a story

Why should you attend this session? Do you like stories? I bet you just said yes. Do you like coding? Safe bet that again you said yes. Let’s combine the two things you like. We will take you on a trip through the forests of refactoring conditionals, passed the mountains of the golden master, down the river of extracting pure functions and into the mount of decomposition. We will not just tell you the story, you will be able to experience while we live code our way through or passed every obstacle in our way.

Spreadsheets are Code

Spreadsheets are often dismissed by developers for not being 'proper programming' but that is not true. Since I have shown that spreadsheets are Turing complete (http://boingboing.net/2013/09/20/implementing-a-turing-machine.html) you have no excuse to diss them any longer. In this session, I will implement various algorithms in Excel to show you its power and elegance.

After all, spreadsheets are ‘live’ and functional, so they have everything going for them. Furthermore they are very fit for TDD and rapid prototyping.

Reasons for attending this talk: Just as learning a second natural language is healthy for your brain (http://www.huffingtonpost.com/dan-roitman/your-mind-on-language-how_b_3902184.html) so is learning multiple programming languages. Thinking about familiar problems like sorting or shortest path in a strange environment like spreadsheet formulas is like a workout for your brain.

Next time you are in need of a quick calculation or prototype, you do not have to waste time configuring a server and deploying your code. Surely not for everything, but for some problems, spreadsheets are really suited and this talk will teach you about how to handle those. Being emerged in the world that many of your colleagues and clients live and breath will make it easier to understand them. Don’t fight spreadsheets any longer, but learn to love them.

Refactoring mount doom: the story of a story

Why should you attend this session? Do you like stories? I bet you just said yes. Do you like coding? Safe bet that again you said yes. Let’s combine the two things you like. We will take you on a trip through the forests of refactoring conditionals, passed the mountains of the golden master, down the river of extracting pure functions and into the mount of decomposition. We will not just tell you the story, you will be able to experience while we live code our way through or passed every obstacle in our way.

The differences between US and European startups from a technical leadership point-of-view.

There are tons of books, movies, videos online about growth-oriented companies. Even if we peel the startup romance off the stories, many of the advices and practicies that work in the US (more precisely in California) just doesn't work anywhere else.

It is sad to see first-time entrepreneurs and investors still try to adapt the same business models that worked for a company ten years back on the other side of the planet, and wonder why they are running toward failure full flank ahead.

Of course, unmaintained appearance may not be the synonym of coolness in your city, but we will discuss deeper problems, such as:

• Cultural and language diversity in the area
• Market size
• Legal environment and regulations
• Technology shift

What Is Continuous Inspection, Anyway?

A critically overlooked aspect of Continuous Delivery is the need to maintain the internal quality of our software to enable us to sustain the pace of innovation. Experience teaches us that Continuous Delivery is not sustainable without Clean Code.

Just as with functional bugs, code quality 'bugs' are best caught early, and for this we find we need some kind of Continuous Testing approach to raise the alarm as soon after code smells are introduced as possible.

Continuous Inspection is the missing discipline in Continuous Delivery. It is essentially continuous non-functional testing of our code to ensure that we will be able to change it later.

In this tutorial, participants will learn how to implement Continuous Inspection using readily available off-the-shelf tools like Checkstyle, Simian, Emma, Java/NDepend and Sonar, as well as rigging up our own bespoke code quality tests using more advanced techniques with reflection and parser generators like ANTLR.

They will also learn about key Continuous Inspection practices that can be used to more effectively manage the process and deliver more valuable results, like Non-functional Stories, Clean Code Check-ins, Build Inspections and Rising Tides (a practice that can be applied to incrementally improving the maintainability of legacy code).

How to use Theory of Constraints to scale big agile development teams?

While implementing Scrum and shortening Time To Market in large financial institution we were slowed down because of obstacles in planning and analysis. I came with the idea to use Theory of Constraints which helped us to calculate real TTM and gave us hints how to release faster and cheaper. Now they're ready to change direction anytime and do releases more often.

Presentation is suitable for people in organizations trying to lower workload of releases.

Lean UX and Agile development taking the Public sector to new levels

As companies and organisations of all shapes and sizes come to grips with the fact that UX is critical to project and product success, a common question resurfaces time and again: How do we add Lean UX practices to our current Agile process?

Bringing the practice of Lean UX in to an organisation could in some cases cause apprehension. What they really want to know is, how this practice can be adopted in to their current process without having a negative impact on their output? Where companies have a mature agile process, they may be reluctant to try something new which could upset that balance. However, with experienced UX specialists, a highly collaborative team and iterative process we can show you the Lean UX techniques to ensure a better understanding of user needs.

Taking back BDD

Behaviour Driven Development (BDD) and Domain Driven Design (DDD) seen a great growth in adoption in recent years. We are all creating new practices and tools that try and bring these two very important modern methodologies together. What if we have it backwards and they were actually together all along? What if most of the misunderstandings and challenges we face in implementing BDD are spawned from the very simple mistake of us separating something that was created as a whole? In this talk we'll delve into BDD as it was meant to be done from the beginning and look at its very rooted connection with the software design.

Understanding Craftsmanship

Marcello reflects over the craftsmanship manifesto and its elements to uncover some interesting insights regarding the application of the underlying principles in real life projects and in the context of organisations and communities struggling to live up to the expectations it creates.

Managing global teams : Lessons learned

Remote working is an increasing trend for several startups and 'traditional' companies. Hiring people globally decreases costs but it hides a lot of risks and difficulties, especially when it comes to manage remote workers. Different cultures, time-zones, not face-to-face interactions are some of the problems that a development manager or a technical leader will have to solve.

During the last months I had the chance to to manage lots of development teams all around the world. In this session I will share with you my experience and discuss some great ideas and practices I have learned and followed.

Presentation structure

• Remote working trends
• Global teams and their problems
• How to build a team
• Effectively managing remote workers
• Evaluating performance / productivity

It doesn't work that way in enterprise

One man's story about the trials and tribulations of being an 'enterprise' developer. If you think you've experienced corporate dogma and constraint - the extent of it in this tale will put everything in perspective! I'll also give you proof that despite what anyone says, things can get better.

We've all heard it... or something similar. There's probably one senior guy at work who tells you this at least once a month. You've got an idea for an amazing new feature or practice that's going to save your company both time and money, but it's too 'cutting edge'; your management fears the unfamiliar and you are cruelly stifled.

'It doesn't work like that in Enterprise' is a passionate and motivational story about my journey as a developer in the face of one of the worst fallacies in our industry. The extremes of my experience will make you laugh & cry in equal measure, and maybe help put your own frustrations into perspective. Just remember, it does get better... and you probably got off very f***g lightly!

Bringing Agile Concepts to Operations

With the rise of automation, configuration management and infrastructureas code, sometimes working in operations is only a hair's breadth away from software engineering.

Also, with the rise of the DevOps, there's been great strides in breaking down the barriers between operations and development, getting people out of silos and communicating more.

If that's so, what approaches can we take from from agile development to help operations become more agile and iterate faster?

Closing Keynote

Information to follow

Use your type system; write less code

Building a large application often feels like an exercise in futility. No matter how we do it, even test-driving everything, there’s always one more bug. We make one thing more robust and another falls over. Anything that can go wrong will go wrong. And when that massive change request comes in, building a new feature while keeping the bugs out is even harder.

So what if things couldn’t go wrong?

I want to talk to you about types.

You’re probably familiar with classes and at least one variant of object-oriented programming. You know what types are and you use them all the time. So what are you missing?

First of all, I want to talk about readability. Often, we use classes for enhancing the behaviour of values. Let’s do the opposite: reduce the behaviour. It's the Unix philosophy. 'Do one thing, and do it well.'

Secondly, I’d like to look at flexibility, and how to write code that really is changeable without spending weeks and introducing regressions. We’ll look at polymorphism, composition, and a few refactoring techniques.

Thirdly, let’s wander into the scary-sounding halls of correctness. We’ll look at our type system not as an encapsulation mechanism but as a theorem prover, using it to iron out potential bugs before they can take root.

Finally, we’ll venture into the halls of optimisation, using our new types to improve performance without damaging the quality of our code. We’re going for maintainable code that’s fast too.

Programming languages have come along leaps and bounds in the last 20 years, but often we code as if we’re still writing in that original dream of Bjarne Stroustrup, 'C with Classes'. We can do so much better.

Designing and building a micro-services architecture. Stairway to heaven or a highway to hell?

Micro-services and micro-services architecture are the next hype in software development. Websites and blogs are full of introducing posts, the first books are being written and the first conferences organized. There’s big promises of scalability, flexibility and replaceability of individual elements in your landscape. However, when you are knee deep in the mud as a software architect at an insurance, it is very hard to find help on how to design applications and components in a micro-services architecture. During this talk Sander Hoogendoorn, discusses the long and winding road the insurance company where he’s acting as the lead software architect has taken to implement their business processes in a micro-landscape. Sander will show how this company is modeling requirements in a micro-landscape using smart use cases, and will explain the difficulties and the lessons learned, using many real-life examples.

Opening Keynote

Information to follow

Software architecture vs code

Software architecture and coding are often seen as mutually exclusive disciplines, despite us referring to higher level abstractions when we talk about our software. You've probably heard others on your team talking about components, services and layers rather than objects when they're having discussions. Take a look at the codebase though. Can you clearly see these abstractions or does the code reflect some other structure? If so, why is there no clear mapping between the architecture and the code? Why do those architecture diagrams that you have on the wall say one thing whereas your code says another? In fact, why is it so hard to automatically generate a decent architecture diagram from an existing codebase? Join us to explore this topic further.

Surrender the illusion of control

Developers love to get a program into their heads and hold it there. When we’re working on a problem alone this feels like the best way to work, it keeps the code and our ideas connected in a way that feels good and seems to amplify productivity.

This doesn’t scale.

What happens when you add more heads? What happens when the problem is so complex the solution is too big to fit in your head?

We’ll look at how we can give up the illusion of control but keep that connection between the code and the ideas – even when we are working with other people on complex problems.

Exploring alternatives to software estimation with #NoEstimates

Estimation in the software development industry is a contentious subject, seemingly a black art that can have serious consequences on the success or failure of a project, and often a business. This talk explores alternative ways and offers a critique of the #NoEstimates movement.

Tell, don't ask

Test driven development follows this pattern

• Setup
• Execute
• Verify the new state

Asking the system under test for its new state has traditionally been done to check the new state.

This can create problems with the Law of Demeter. The system under test knows unnecessary much about the objects it is collaborating with. This may not seem like a big deal, but when you try to break things apart and replace an object you may end up with refactoring a lot more than you actually wanted. It is like pulling up a tree with the roots. You will damage the ground a lot and have tons of soil among the roots afterwards.

Another approach would be to tell the system under test what to do and verify that it has been told properly. This will reduce coupling between objects, not break encapsulation, allocate functionality in the proper place, name functionality better according to the problem domain and prevent classes from being feature envy.

I will show some examples where I ask for the state and then compare them when I apply Tell – don't ask and discuss the differences.

Level Up Your Tests

Testing has been part of the software delivery lifecycle since… forever. Now, Agile methodologies make testing part of everyone’s responsibilities. But despite this, despite big steps forward with TDD, BDD, and other approaches which bring automated testing to the forefront of the development process, many developers still behave as if testing is a second class citizen.

What can you do to help developers a) write tests b) write meaningful tests and c) write readable tests?

Trisha will talk about her experiences of working in a team that wanted to build quality into their new software version without a painful overhead – without a QA / Testing team, without putting in place any formal processes, without slavishly improving the coverage percentage.

The team had been writing automated tests and running them in a continuous integration environment, but they were simply writing tests as another tick box to check, there to verify the developer had done what the developer had aimed to do. The team needed to move to a model where tests provided more than this. The tests needed to:Demonstrate that the library code was meeting the requirements document in a readable fashion what those requirements were, and what should happen under non-happy-path situations provide enough coverage so a developer could confidently refactor the code

This talk will cover how the team selected a new testing framework (Spock, a framework written in Groovy that can be used to test JVM code) to aid with this effort, and how they evaluated whether this tool would meet the team’s needs. And now, two years after starting to use Spock, Trisha can talk about how both the tool and the shift in the focus of the purpose of tests has affected the quality of the code. And, interestingly, the happiness of the developers.