Modern Software Engineering

In this session, continuous delivery pioneer David Farley illuminates durable principles at the heart of effective, modern software development.

He distills the discipline into two core exercises: learning and exploration and managing complexity.

For each, he defines principles that can help you improve everything from your mindset to the quality of your code and describes approaches proven to promote success.

Lean Code

Lean has been applied as a toolkit to fine-tune development processes and organisational workflow, but what does it mean when we apply the practices to the detail of the code, the practices used to develop it and the people who develop it? What does Lean Code and its creation look like? There is a need to move beyond often separated worlds of software craft and agile development, to properly embrace code in its detail, but to also connect it more completely to the flow of business and the intelligence of people around it. To move beyond simple exhortations of clean code to something more human. This talk offers a fresh look at Lean principles and practices from the perspective of the code and the coder, rather than the usual scale of the organisation and the development process.

All The Little Things

In theory, object-oriented applications consist of small, interchangeable objects which know almost nothing about one another. In reality, many apps contain big classes full of long methods built of many conditionals. Our classes act more like procedures than objects; they know too much, they contain code we can't reuse, they're hard to change and they get worse every time we do so. This talk uses the principles of object-oriented design to break ugly procedures into pleasing objects which have just the right balance of knowledge and ignorance. It bridges the gap between theory and practice and reveals a few simple secrets of OOD that you can use to convert confusing, unmaintainable faux-OO code into understandable, reusable, easily testable objects.

Code Red: The Business Impact of Code Quality

Code quality is an abstract concept that fails to get traction at the business level. Consequently, software companies keep trading code quality for new features. The resulting technical debt is estimated to waste up to 42% of developers’ time, causing stress and uncertainty, as well as making our job less enjoyable than it should be. Without clear and quantifiable benefits, it’s hard to build a business case for code quality.

In this talk, Adam takes on the challenge by tuning the code analysis microscope towards a business outcome. We do that by combining novel code quality metrics with analyses of how the engineering organization works with the code. We then take those metrics a step further by connecting them to values like time-to-market, customer satisfaction, and road-map risks. This makes it possible to a) prioritize the parts of your system that benefit the most from improvements, b) communicate quality trade-offs in terms of actual costs, and c) identify high-risk parts of the application so that we can focus our efforts on the areas that need them the most. All recommendations are supported by data and brand-new research on real-world codebases. This is a perspective on software development that will change how you view code. Promise.

Towards Evolutionary Architecture

Big up front design is discouraged in agile development. However, we know that architecture plays a significant part in software systems. Evolving architecture during the development of an application seems to be a risky business. In this presentation, we will discuss the reasons to evolve the architecture, some of the core principles that can help us develop in such a manner, and the ways to minimize the risk and succeed in creating a practical and useful architecture.

The Economics of Software Design

Every month, someone new asks me the question, "How do I convince my manager to let me refactor?" While it's true that a manager shouldn't constrain the programmer's plans to deliver high-quality code, the fact remains that some organisations allow their managers to assert this level of micro-control. In this talk I outline a set of models for justifying evolutionary design with basic economic concepts that relate directly to delivering, planning, and funding software projects. This talk will provide you with a solid argument to meet any skeptic's rational objections to writing tests first and letting both low-level design and architecture emerge.

How To Make Your Code Suck Less

In this session, I'll go beyond basic clean coding techniques and reveal some of my favorite (and very effective) ideas, heuristics, and practices for making real-world enterprise applications cleaner. We'll touch on many topics: naming, levels of abstraction, dealing with large objects, OO design, and much more. The examples will be taken from real enterprise projects.

TDD Revisited: Where Did It All Go Wrong

Since Kent Beck wrote the book on TDD in 2002 a lot of words have been dedicated to the subject. But many of them propagated misunderstandings of Kent's original rules so that TDD practice bears little resemblance to Kent's original ideas. Key misunderstandings around what do I test, what is a unit test, and what is the 'public interface' have led to test suites that are brittle, hard to read, and do not support easy refactoring. In this talk, we re-discover Kent's original proposition, discover where key misunderstandings occurred and look at a better approach to TDD that supports software development instead of impeding it. Be prepared from some sacred cows to be slaughtered and fewer but better tests to be written.

Monolith Decomposition Patterns

Big Bang rebuilds of systems are so 20th century. With our users expecting new functionality to be shipped more frequently than ever before, we no longer have the luxury of a complete system rebuild. In fact, a big bang migration of a monolithic architecture into a microservice architecture can be especially problematic, as we’ll explore in this talk.

We want to ship features, but we also want to improve our architecture, and for many of us this means breaking down existing systems into microservices. But how do you do this while still regularly releasing new features?

In this talk, I’ll share with you some key principles and a number of patterns which you can use to incrementally decompose an existing system into microservices. I’ll also cover off patterns that can work to migrate functionality out of systems you can’t change, which are useful when working with very old systems or vendor products. We'll look at the use of strangler patterns, change data capture, database decomposition and more.

Clean Agile: Back to Basics

Robert C. Martin (Uncle Bob) reintroduces Agile values and principles for a new generation of programmers and nonprogrammers alike, striping away misunderstandings and distractions that over the years made using Agile difficult.

How We Build Spring Framework

Coming soon.

How to Interview Developers (and enjoy it)

If you've been in the tech industry for any length of time, you've probably been asked to participate in interviewing. Lucky folks will receive some basic training from their employer, but most are expected to just figure it out. It can be time-consuming, nerve-wracking, and tedious. You probably don't enjoy doing it, and that can lead to bad hires and painful experiences. Kris has participated in more than 250 interviews at AWS - as both an interviewer and a hiring manager - and has finally come to embrace the process. She'll provide practical tips you can use to conduct more effective interviews, saving you time and making the whole process a lot more enjoyable.

The Road From Dev to Engineering Director

Looking at my LinkedIn Profile and seeing my current title as "Director of Engineering," you might feel that my career was an easy straight line from Dev to Director. You are wrong!

I had many turns back and forth. In the 15 years of my career, I went from being The "Tech Support" guy to Programmer to Project Manager to QA, back to Engineering/DevOps and Agile Consulting, and finally to Engineering Management in the Mobile space, where I finally found myself in the last five years.

In this talk, I will tell you how all the left and right turns I took on the road prepared me to be where I'm with a much more solid foundation than the 'straight-line career path approach" would ever do.

The Most Dangerous Phrase

Some advice is timeless; it ages like a fine wine. Each time you revisit it you discover a nuance, a new connection to something else. As you grow, the advice is waiting there to reveal another layer you had never considered.

Some advice is a product of its time; it ages like milk. It starts fresh, then it begins to smell, and eventually it rots and can even become harmful! It made sense in the context and constraints of its day, but things have changed and it is no longer relevant.

As Admiral Grace Hopper famously said: "The most dangerous phrase you can use is 'But we've always done it this way!'" Daniel believes this is why so many people have an almost religious zeal for SOLID, Scrum, and other antiquities.

In this session, Daniel argues from first principles why ideas like SOLID and Scrum made sense in their day, over a quarter century ago, and why they have been superseded and should now be considered harmful. For contrast, he suggests Continuous Delivery and lean product development are ageing like fine wines. If there is time, he will show how methods like SAFe have never been relevant and never will be, but can be very appealing to a certain kind of manager.

#NoEstimates – Why, When, and How

This keynote presents my (and many other's) thinking about #NoEstimates. It argues that estimation is a bad thing, particularly in the Agile world, and presents ways to plan that don't involve estimation.

The Architect Elevator: Redefining The Architect's Role

Many large enterprises are feeling pressure: digital disruptors attack with brand-new business models and no legacy; the Facebook generation” has dramatically increased user expectations; and access to state-of-the-art technologies has been democratized by cloud providers. This is tough stuff for enterprises that have been, and still are, very successful, but are built around traditional technology and organizational structures. “Turning the tanker”, as the need to transform is often described, has become a board room-level topic in many traditional enterprises. Chief IT Architects and CTOs play a key role in such a digital transformation endeavor. They combine the technical, communication, and organizational skills to create business value from a tech stack refresh, to look behind buzzwords like “agile” and “DevOps”, and to build a technology platform that assures quality while moving faster. They do so by riding the “Architect Elevator” from the penthouse, where the business strategy is set, to the engine room, where the enabling technology is implemented. I rode that elevator for 5 years in a major financial services organization and am now advising major corporations on their digital journey. I collect stories from the daily life of IT transformation and package them in lighthearted, but meaningful anecdotes.

Vertical Slice Architecture

Moving from a layered architecture to a vertical slice architecture can be a bit daunting. We remove abstractions, complex structures, and focus building on the axis of change, then what's next? What new structures, patterns, and policies will need to be introduced in this style of architecture? How will we deal with common business functionality, and where do concepts like CQRS and DDD fit in? In this session, we'll introduce the idea of vertical slice architectures, and dive into the patterns, tools, and techniques used with slices. We'll also cover how you can fit vertical slices into different kinds of systems, from desktop, SPA, and normal MVC applications. Finally, we'll look at some of the new challenges that come with slices and layers, and how a different approach provides a much more maintainable end result.

Developer Joy – How Great Teams Get s%*t Done

Software development has become more complex over the years: Building and running a distributed architecture in the cloud, ensuring observability, discussing user experience with design and product, and keeping a healthy balance between dev speed and code quality isn’t easy. Just be agile and practice DevOps, they say.

Join Sven and learn how great software teams measure and improve their developer productivity, coordinate work across teams, run microservice teams, and create a healthy and joyful engineering culture. Always backed up by data instead of opinions.

The talk will demonstrate how teams at Atlassian and other tech companies faced development challenges, reinvented themselves, and created new ways of working to get s%*t done.

The Early Days of id Software: Programming Principles

As co-founders of id Software, John Romero and John Carmack created the code behind the company's seminal titles. The principles they defined through experience in id’s earliest days built upon one another to produce a unique methodology and a constantly shippable codebase. In this talk, John Romero discusses id software’s early days, these programming principles and the events and games that led to their creation.

Scaling Yourself

As information workers, we are asked to absorb even more information than ever before. More blogs, more documentation, more patterns, more layers of abstraction. Now Twitter and Facebook compete with Email and Texts for our attention, keeping us up-to-date on our friends dietary details and movie attendance second-by-second. Does all this information take a toll on your psyche or sharpen the saw? Is it a matter of finding the right tools and filters to capture what you need, or do you just need to unplug.