Jules May's Speaker Profile @ Sessionize

Why programming is fiendishly difficult (even after all these years) and what we can do about it

In the 1950s and 1960s, when we first started writing software at industrial scale (and “computer” was a job, not a machine), programming was really hard! It was slow, error-prone, and demanded complex rituals and incantations to make anything work. Back then, software was a byword for missed deadlines, blown budgets, and machines going haywire. In short, software was a mess.

Seventy years on, we now have new programming tools (mostly: languages), new programming paradigms (mostly: objects), and new programming methodologies (mostly: agile). And yet, programming is still really hard, our software systems are still a mess - albeit a rather bigger mess than in the past - and we’ve given up even trying to budget large developments.

Why is programming so difficult? In contrast to nearly every other engineering discipline (which routinely use self-stability, failsafety, and feedback to build robust and resilient systems) software amplifies disturbances, and so builds systems which are inherently brittle. It doesn’t matter how carefully we error-check results or how assiduously we null-check our pointers, sooner or later a disturbance will start a crack in the code, which will spread to the whole system.

And yet, when it comes to it, we can create software so good we can entrust our lives to it. Aircraft, medical instruments, even the internet all work pretty much perfectly pretty much all the time. The programmers who create these exquisite systems: what do they do that the rest of us don't? What can we learn from them?

In this talk, Jules explains the fundamental difference between software and other kinds of engineering, will explore some of the things we do to strengthen our code which (in fact) make matters worse, and will introduce a paradigm for creating code which is robust and reliable even in the presence of errors. He shows that it takes less time, costs less money, and dramatically improves your system’s security to build highly-reliable software than it does to build the buggy variety.

Quantum Computing Workshop

Everyone's heard about quantum computers - how they'll be able to solve every computational problem in the blink of an eye, decrypting every coded message, and spilling our secrets across the internet. That’s if they ever get delivered: for all the talk, nobody seems able to construct a working quantum computer. So is the whole idea nothing more than fairy dust?

Actually, quantum computers do exist, and we can use them to run real algorithms. Within a few years, quantum computers are going to be a useful part of the programmer’s armoury, routinely solving problems in optimisation, recognition, machine learning, and simulation that no other technology can handle.

(Optionally) Quantum computers are worth studying now because they’re just about ready for commoditisation and large-scale adoption, in the same way that AI systems are now being commoditised. And the kind of techniques that are used to tame uncertainty in quantum systems can also be used to tame unreliability in networks of conventional computers.

This session explains what a quantum computer is, why it is so different from a conventional computer, and how we design quantum algorithms. It will explore and implement a number of classical algorithms, and discuss how to design new algorithms.

At the end of this workshop, you will be able to apply quantum computing techniques to your own real-world problems.

GPU programming: for the toughest jobs on planet Earth

For decades now, most computers (and even most phones) have come with some kind of graphics accelerator, and for most of that time, most of us have used it just for creating game graphics. But GPUs are capable of much more than that: they're general-purpose compute engines that can be used to accomplish a whole range of tasks from optimisation to modelling.

Today, new technologies are going mainstream: computer vision systems, generative AI, large language models, and more can demand enormous compute resources, and GPUs are ideally placed to shoulder that load. Form small graphics processors on PCs, through complex processor engines with a few thousand cores, up to rented grids with tens of thousands of cores, GPUs represent a uniquely powerful technology for today's workloads.

But how do they work? How can you coordinate the efforts of tens of thousands of threads when it's hard enough coordinating a handful on a regular CPU?

In this session, Jules will introduce GPU programming. You'll learn:
- What is the GPU architecture, and why it is different from a regular CPU;
- What kinds of workloads are well-suited to GPU, and what aren't;
- The compiler and virtualisation technologies by which you can access GPUs: CUDA, OpenCL, and OpenGL;
- How to write, debug and validate your own kernels, using examples from graphics, data science, and machine learning.

By the end of this session, you'll be able to leverage the power of GPUs in your daily work.

Infinitely Elastic, Highly Performant, Relational databases.

Cloud-native computing offers the promise of infinite scalability -as your application makes greater demands on the infrastructure, the infrastructure magically grows to accommodate it. This works for every part of your application, except for the database.

Normally, you have to make a trade-off between scalability, functionality, and performance. On the one hand, you can deploy single-instances of commodity databases such as Postgres or Mysql, which don't scale well (if at all); or you can deploy highly-scalable engines such as Dynamo which scale infinitely, but cost a fortune and don't provide any complex queries at all (and are very tricky to set up even then). Occupying a middle-ground, there are products like Aurora, Hammer, and Citus, which between them explore a number of ways to achieve scalability in a relational model, but in each case you need to apply complex manual tuning, and even then the performance can collapse without warning.

Jules has been consulting on a project which leverages any commodity engine to deliver infinitely-scalable relational data delivering performance which is guaranteed to be at least as good as the original engine. Because it uses the underlying engine's wire protocol it is a drop-in replacement for a manually-deployed instance.

In this talk, he discusses why distributed relational data is difficult, why the current solutions fall short, and the mathematical background behind a new theory of relations which allows highly-performant distributed systems to be built.

The cash value of technical debt - How to scare your boss into doing the right thing

As developers, we all know how damaging technical debt can be: it decreases velocity, reliability, and daily joy. We know that true agile working requires constant refactoring to bring technical debt down. And yet, in the constant drive to develop new features and (if we’re lucky) fix old bugs, our lords and masters urge us ever onwards, faster and faster, feature after feature, until the codebase collapses into a sticky mess.

Technical debt is not merely a matter of programmer-aesthetics, it genuinely goes the heart of what quality development is all about. But non-technical managers don’t get that. To them, code is just code: if it works: it works, and if it doesn’t: there are plenty of hackers looking for work who are more competent than you.

In order to align our bosses’ needs with ours, we need to be able to express what technical debt is in language which is familiar to them. That is the language of finance. In this talk, we will explore how to quantify the cash value of code, how to measure technical debt, and how to find the actual interest rate the business is paying for it. This is how you can beat the bean-counters at their own game, and put the joy back into your code,

Back to the future: Why analog computers are coming back

Before we had digital electronic computers, we had analog electronic computers, and before then, we had mechanical analog computers. These were very different kinds of machine to our current computers: based on wholly different principles, and using completely different kinds of circuits, they were nevertheless genuinely useful general-purpose computing devices, used for everything from tide prediction to flight control.

Because they can operate with blinding speed at incredibly low-power, these analog technologies are making a comeback, in domains like digital radio and machine intelligence. A new generation of chips is making analog processors as easy to use as a graphics processor.

What do these machines do that's so different from digital computers? What are their limits? How do you program them? In this talk, Jules will explain the principles, describe some basic programs, and demonstrate a real analog computer solving some real problems.

Programming like your life depends on it: A Reliability Masterclass

No matter how much advancement we see in programming tools and hardware technology, software development remains resolutely difficult. The preoccupation of today’s developers is exactly what it was fifty years ago: how can we create software which works reliably, and how we can extend it without breaking it? We just accept that software is inherently flawed, that all software contains bugs like original sin, and we design our processes around that.

But what if it were possible to write software correctly? What if we could create bug-free, maintainable code? And what if it were cheaper, faster and easier to write correct code than to write the buggy variety? What then?

It turns out that it is possible to write perfect code. In fact, perfect code is not that uncommon - we have been entrusting our lives to it for decades. What do they do, these perfect programmers, that the rest of us don’t? What research backs up their practices? Can we all do what they do?

This course is for developers who want to eliminate not just 95% of their bugs, but all of them. What we’ll cover:

Good code
- Why it matters.
- What, exactly, is software quality?
- What does good code look like?
Exceptions
- How exceptions got this way;
- Why exceptions turn a drama into a crisis;
- What exceptions should have been;
- The (only) valid use of an exception;
- Exception quarantine
Classes and Objects
- The myth of resuability
- Getaway classes (better than flat-pack classes)
- Better living through immutability
- Algebraic groups
- Nullary objects
If considered harmful
- The if anti-pattern, and why debugging makes bugs worse
- Decision trees
- Down-converting factories
Closure
- Exception quarantine redux
- Closures beat dependency injection
Isolation: intra-program firewalls
- Fly-by-wire
- Layering
- Publish and be damned
Concurrency
- Down with multi-threading!
- Immutability redux
Testing
- Why we test
- Why testing doesn't find bugs
- How to do automated testing right
- How to do manual testing right
Working with legacy code
- Debug the roots, not the leaves
- String-typing is non-typing
Toolmaking: Getting emergence on your side.

(Naturally, we won't be able to cover all these. But I have material for all these, and I can pick and choose to suit the audience.)

If considered harmful, or how to eliminate 95% of your bugs in one easy step (Updated)

In 1968, CACM published a letter from Edsgar Dijkstra, called “The GOTO Statement considered harmful”. In it, he explained why most bugs in a program were caused by gotos, and he appealed for goto to be expunged from programming languages. But Goto has a twin bother, which is responsible for nearly every bug that appears in programs today. In this session, Jules will revisit Dijkstra’s original explanations, and show why If and Goto have the same pathology. He will then go on to explain how to avoid this pathology altogether.

Lean: just the meat

"There is a lot of talk these days about lean development, lean enterprise, lean everything. The way it is conventionally presented, it is a slightly different take on Agile.

But lean isn’t just Agile. It’s both more, and yet much simpler than that. So, what exactly is Lean, where did it come from, and what does it have to do with development?"

How to build a knockout development team

No programmer is an island. Modern programs are created by teams of developers. Everybody knows: you need great teams to build great products – you need to build your teams carefully. But what, exactly, makes a great programming team? Great programming skills? Great interpersonal skills? Working-all-night-becasue-the-boss-has-thrown-a-fit skils? Turns out, it’s none of these. In this session, Jules will reveal that what makes a programming team great is exactly what makes any other team great – and most programming teams don’t have it.

Version Control for Data (New)

"Few of us today would consider developing code without the support of a version-control system. And yet our data - which is the lifeblood of our business - tends to exist only in a “present tense”, with no versioning at all.

What would it mean to version data? What would versioned data look like, and how would it differ from versioned code? Most importantly: what would be the business benefits of routinely version-controlled data? In this talk, Jules presents some of the key learnings from a recent project he led which was set up to answer these questions."

Introduction to Problem Space Analysis

How do you design a large system? The architecture of any system is crucial to its success – get this wrong, an the project may never recover. And yet, we are expected to deliver designs that last 5, 10, sometimes 30 years into an unknowable future.

Problem Space Analysis is a technique that informs and documents system designs by anticipating and defining the variabilities of an evolving, long-lived system. It informs the architectural design so that it can accommodate those changes, and it delivers a change-tolerant pervasive language to unify and coordinate the development effort.

In this session, Jules will introduce the principles of Problem Space Analysis, and will show how those principles can be translated into architectures and thence into working systems, even while the goalposts are moving.

Hello, Quantum World!

How would you like to see an actual, quantum computer, actually working?

Everyone's heard about quantum computers - how they'll be able to solve every computational problem in the blink of an eye, decrypting every coded message, and spilling our secrets across the internet. That’s if they ever get delivered: for all the talk, nobody seems able to construct a working quantum computer. So is the whole idea nothing more than fairy dust?

Actually, quantum computers do exist, and we can use them to run real algorithms. Within a few years, quantum computers are going to be a useful part of the programmer’s armoury, routinely solving problems in optimisation, recognition, machine learning, and simulation that no other technology can handle.

(Optionally) Quantum computers are worth studying now because they’re just about ready for commoditisation and large-scale adoption, in the same way that AI systems are now being commoditised. And the kind of techniques that are used to tame uncertainty in quantum systems can also be used to tame unreliability in networks of conventional computers.

This session explains what a quantum computer is, why it is so different from a conventional computer, and how we design quantum algorithms. Finally, it will show a simple, “Hello, Quantum World” program running on real quantum hardware.

The mirror of Erised: The true value of AI in an over-hyped market

Since GAN appeared on the scene, delivering products such as ChatGPT and Dall-E, there has been a great deal of excitement and hype over what these technologies will become. Will they become our servants, solving all our problems for us, or will they become our masters, keeping us as pets for as long as we are useful to them? Will they disappear into a post-truth black hole of their own making, or will they lie around unused and rusting because they’ve failed to deliver any value at all?

The thesis of this talk is: none of these outcomes is correct. AI technologies really do have value, but not the value we are expecting.

Starting with a historical and technological perspective, Jules explores the state of the current AI landscape and how it came to be this way. He unpacks the reasons behind the previous three “AI winters”, and describes why another, even colder winter is inevitable (where a lot of people are going to lose a lot of money). Finally, he points the way towards a more adult and less hysterical understanding of AI’s promise, and how to invest in these technologies despite the current, misguided mania.

Why software breaks, and how we can fix it

Today, almost everything works because of the software inside it. And yet, software contains bugs. No matter how carefully we write our code, no matter how thoroughly we test it, sooner or later it will break. If our software doesn't perform reliably, neither can anything else.

Why is it so difficult to create reliable programs? In contrast to nearly every other engineering discipline (which routinely use techniques such as self-stability, fail-safety, and feedback to build robust and resilient systems) software amplifies disturbances, and so builds systems which are inherently brittle. It doesn’t matter how thoroughly we error-check results or how carefully we catch exceptions, sooner or later a disturbance will start a crack in the code, which can spread to the whole system. That’s why we have to switch it off and switch it on again.

it doesn't have to be this way. We can write intrinsically stable software which uses the lessons from 5000 years of engineering practice. We can make code that consistently and provably behaves perfectly, even when it is impacted by stressors from outside and defects from within. The people who build the software to which we entrust our lives: this is how they do it. And it turns out, once you know the secret, it costs much less money and takes far less time to build code that works perfectly than it does to wrestle with the buggy variety.

In this talk, Jules explains the fundamental difference between software and other kinds of engineering. He explores some of the anti-patterns that we believe will strengthen our code but which (in fact) make matters worse, and introduces a paradigm for creating code which is robust and reliable even in the presence of errors.

This is the key to flawless software, delivered faster.

Speaker

Jules May

Actions

Links

Area of Expertise

Topics

Sessions