Agenda

Nerd out and learn from
engineers, hackers, designers, and PhDs.

The place to be for enthusiasts, students, and professionals across software, product, cloud, data, UX, games, infrastructure, open source, security, AI, and everything in between. Come on down, and bring along your team.

Hall 1AHall 1BRoom 1ARoom 1BWorkshops

08:30

09:00

09:30

10:00

10:45

11:15

11:30

12:00

13:00

13:15

13:30

13:45

14:00

14:15

14:30

14:45

15:00

15:30

16:10

16:50

18:00

Registration

08:30 (30 minutes)

Coffee

09:00 (30 minutes)

Opening

09:30 (15 minutes)

😀Coming soon

10:00 (30 minutes)

Erased From the Commit Log: Forty Years of Queer Computing, and the Systems We're Building Next

10:00 (30 minutes) · Hall 1B · Talk · Introductory · Wildcard

In January 1976, a shipping clerk in Belfast had his home searched and his private papers seized. Five years later, Jeffrey Dudgeon won a case at the European Court of Human Rights that decriminalised homosexuality in Northern Ireland. It was 1988 when Norris v. Ireland put the Republic on the road to decriminalisation. These rulings are younger than some of the companies we work for. Our industry was built by people who had to hide to do their work. Alan Turing died a convicted criminal. Lynn Conway was fired by IBM in 1968 and rebuilt a career from nothing, then wrote the methods that every chip designer still uses. Sophie Wilson designed the instruction set that runs on almost every phone in this hall. Most of us learned their architectures without ever learning their names. This talk traces that history forward into the code we ship today: the name field that can't hold both a legal and a chosen name, gender modelled as an enum, the deadname that survives in every backup and audit log, the identity check that fails on mismatched documents, the retention policy that turns a user record into an outing risk in the wrong jurisdiction. These are architecture decisions with owners and tickets, not HR problems. We'll close by considering what the next decade asks of us and why designing for the edges has always produced better systems for everyone in the middle. Key takeaways * Named, specific ways production systems fail queer users - identity modelling, audit trails, verification flows, data retention - and design patterns that can provide solutions * A working test: how to audit your own schema and logs for assumptions that only hold for the default user * Why inclusive design consistently improves reliability and usability for the whole user base, with the mechanism, not the platitude * A pocket history of queer computing you can cite, from Belfast in 1981 to the ARM core in your pocket

Adam D'Arcy

Adam Darcy is a Principal Engineer, Architect and Researcher with over a decade of experience leading engineering teams across HCI, cybersecurity, and AI. He provides cross-organisational cybersecurity leadership, owning threat modelling, vulnerability detection and response, and secure software delivery practices across platform and AI systems. Between 2022 and 2025, he conducted research into cyber resilience as part of a partnership between Workday, Technological University Dublin, and the IDA. Experienced across the full software delivery lifecycle, he collaborates closely with product, UX, research, cybersecurity, legal, privacy, and senior leadership stakeholders to deliver secure, resilient systems at scale. A recognised researcher in HCI, cybersecurity, and AI, he has published and presented internationally on these topics. Adam is also a committed champion for LGBTQ+ representation and diversity in technology, dedicated to building inclusive platforms and engineering cultures where all contributors can do their best work.

Chaining the Unchainable: Finding and Exploiting Logic Flaws in Modern Web Architectures

10:00 (30 minutes) · Room 1A · Talk · Intermediate · Security

Most scanners will never find these bugs. This talk is about what happens when you chain enough of them together anyway. Spoiler: it ends in RCE and full tenant isolation bypass. Business logic flaws are unglamorous. They don't have CVEs, they don't get blog posts, and individually they'll barely register as medium severity on most reports. But in the microservice-heavy, federated identity, multi-tenant environments most organisations are running today, these small mismatches compound. The interesting stuff happens at the joins, like where an API gateway hands off to a downstream service, where an event queue trusts state it shouldn't, or where OAuth flows have one assumption too many baked in. This session walks through three attack chains pulled from real engagements. This is not sanitised theory. We will look at actual proxy logs, HTTP pairs, and the exact moment each system broke. The three paths covered include: 1. Race conditions in async queues: Abusing state validation gaps in event-driven architectures to push through unauthorised transactions. 2. Token propagation abuse: Exploiting the trust gap between an API gateway and its downstream services to chain into deep IDOR. 3. OAuth state-machine quirks: Turning minor implementation oversights into persistent session hijacking. The goal isn't just to show what broke. Attendees will come away with a method for reading an architecture diagram and spotting where the logic synchronisation is weakest, a framework for building these chains deliberately, and concrete design-layer fixes that actually address the root cause rather than just patching symptoms. Key Takeaways for Attendees: - A clear method for analyzing an architecture diagram to spot where logic synchronization is most vulnerable. - An adversarial framework for systematically building exploit chains out of low-severity context flaws. - Concrete, design-layer remediation strategies that address the root cause of these architectural gaps.

Raj Dhruv

Application Security Specialist at Black Duck I'm an Application Security Specialist at Black Duck, spending my days handling penetration testing, vulnerability assessments, and digging into the weeds of web app flaws. Before this, I was a Machine Learning Researcher at Rapid7, where I built models to predict and filter out false-positive noise inside InsightIDR. I also dropped by Ulster University recently as a guest lecturer to talk to the students about real-world security engineering, and I hold an MSc in Applied Cyber Security from Queen's University Belfast. I like breaking things, figuring out why complex logic fails, and making sure developers have the actual blueprints to fix it.

Ranking Every Trainer in Pokemon Red

10:00 (30 minutes) · Room 1B · Talk · Intermediate · Wildcard

Which Pokémon trainer is the very best in Pokémon Red? The answer may surprise you! Pokémon Red is one of my favorite games. I probably went through hundreds of AA batteries playing it. At the start of this year I put together a small project to rank every single trainer by making them all fight each other over, and over, and over until I found out who was the best. In this talk I'm going to talk about how the Game Boy system works, how I made every trainer battle each other, how I ranked the results (ignoring good scientific practices), and how I saved my CPU from melting itself. Topics involved: * The Game Boy system * Console emulation * Pokemon Red * Assembly * Python * The Cloud (minor)

Nathan Sullivan

I learned to code when I was around 14 and my dad handed me his old C++ textbook. About 10 years ago, after going to Queen’s University Belfast to study computer games design, I realised game devs were underpaid and overworked, so I moved to Dublin to work for AWS. After a couple of moves I’m working for Business Insider in Belfast.

Create You First Linter

10:00 (1 hour) · Workshops · Workshop · Intermediate · Engineering

Over the years, I’ve built several linters and in this session, I’ll show you how surprisingly simple it is to build your own linter in Go, but also,how powerful it can be. You’ll learn how to create a linter from scratch, plug it into golangci-lint, and use it to enforce your team’s style guide automatically in CI.

Manuel Doncel Martos

I am a Technical Lead with experience in building distributed systems. I have commercial experience in Java and Go but I'm passionate about learning new programming languages, which is why you'll also find me exploring other languages like Python and Rust. I enjoy tackling challenges, experimenting with different tech stacks, and growing as a developer. I always look how to improve the code quality, and for that I created several linters that I use in many of my projects.

Deprecated: The role was redundant. Not me.

10:45 (30 minutes) · Hall 1A · Talk · Introductory · Career

When my manager asked for "a team update", I had no idea I was about to enter one of the least-talked-about experiences in a professional career. And yet within days I discovered something uncomfortable: almost everyone I told had quietly been through something similar. The nods. The knowing looks. The "yeah, that happened to me too." So why does nobody talk about it? Redundancy is surprisingly common, poorly understood and almost entirely absent from any conversation about career resilience... until it happens to you. A bit like pensions, really. A few people in the loop. Most people beside it. Almost nobody prepared. Drawing from my own recent experience and 15+ years working across the software industry, this session maps the redundancy process honestly against the Kübler-Ross five stages of grief. Because it turns out you don't go through it once. You go through it twice- first through the consultation, then again through the job search. And the second loop is the one nobody warns you about. This isn't a session about failure. It isn't toxic positivity about doors and windows either. It's an honest conversation about something that happens to good people doing good work at companies that simply pivot. You can do everything right. The role still gets deprecated. You'll leave with a framework for recognising where you are emotionally if or when it happens, the language to talk about it (to yourself and others) and the reassurance that end of support doesn't mean end of service. Because deprecated isn't deleted. It's just ready for what's next.

Andrew Paul

Andrew writes code and teaches people. Sometimes at the same time. Over a decade in education (schools, colleges, training professional engineers) taught him that technical excellence without communication skills creates brilliant individual contributors but struggling teams. Now consulting on architecture while training engineering teams globally, he helps developers find their authentic technical voice- the one that writes elegant code AND explains why it matters.

🥰Coming soon

10:45 (30 minutes)

Local AI at the End of the Tunnel

10:45 (30 minutes) · Room 1A · Talk · Introductory · AI

In this session we'll combine Local AI, .NET and Dev Tunnels! To begin we'll look at how easy it is to install Ollama, and download a suitable model to run locally, on our own computers. Turning to code, we'll then discover how quick it is to connect to Ollama via our own C# Code, using the Microsoft.Extensions.AI library. Initially interacting via our own Console App. Sidestepping, we'll look at an often overlooked feature: Visual Studio Dev Tunnels. We'll look at the benefits for Web Applications and Web API. Bringing everything together, we'll take our (minimal) Console App code, bake it into a Blazor Web Application, and expose this via a Web Tunnel. Creating a route through to our Local AI installation from any web modern browser.

Mike Irving

A professional developer for over 20 years, based in Macclesfield. For the past 10+ years I have been heavily involved in mobile development, and have utilised both Native code (Swift, Kotlin, Objective-C, Java) and Cross-Platform app development systems including Xamarin, .NET MAUI, Uno Platform and Cordova on different projects. A constant in my journey has been the use of C# / .NET. I also do web development work, and I am equally happy working front-end in HTML, CSS and JavaScript. Microsoft MVP. Co-organiser of Dot Net North and Macc Tech. Regular speaker and presenter.

This code is a crime scene!

10:45 (30 minutes) · Room 1B · Talk · Introductory · Engineering

There’s been a murder. The victim? A perfectly respectable software project. The codebase is riddled with technical debt. Nobody dares touch that module. Deployments require two developers, a spreadsheet and a small religious ceremony. So, who killed it? Was it the developer who copied and pasted the same logic six times? The architect and their seventeen microservices? The product owner who kept changing the requirements? Let’s examine the evidence. Because terrible software isn’t necessarily written by terrible developers. Often, it’s written by good people making reasonable decisions in circumstances that make bad software inevitable. In This Code Is a Crime Scene, we’ll follow the clues from bad code back to the organisation that produced it — and discover why fixing the code without understanding what killed it can leave you with another body two years later. Three key takeaways * Examine the evidence: recognise when technical problems point to deeper organisational problems. * Establish the motive: understand why bad technical decisions were made before trying to fix them. * Prevent the next murder: change the conditions that created the mess, not just the code they produced.

Nick Cousins

Nick Cousins has spent nearly two decades building software, leading technical teams and occasionally wondering how everything got quite so complicated. He began his career as a software developer before becoming a technical lead, manager, CTO and eventually founding his own software company. Today, he works as an independent software developer and consultant, helping organisations untangle the people, process and technical problems that get in the way. He is particularly interested in what happens where software and people collide: how teams make decisions, how organisations shape the systems they build, and why perfectly sensible people sometimes produce completely baffling code. Nick lives in Belfast, is an enthusiastic reader of murder mysteries, and remains cautiously optimistic that the next rewrite will fix everything.

Introduction to Python and Electronics - code your own game controller

11:15 (1 hour) · Workshops · Workshop · Introductory · Engineering

**Vicky Twomey-Lee**Coding Grace, Diversity in Tech Advocate

**Michael Twomey**Principal engineer and perpetual tinkerer

Ever wonder how Python and electronics work together? What's CircuitPython? This exciting electronics-based workshop brings creativity and technology together to enhance the gaming experience. Learning how to build a custom game controller, participants will develop skills to tailor the design and functionality of their gaming preferences. 👉 What you need to bring is your laptop with Thonny installed - https://thonny.org We will provide the rest of the components and materials needed for the workshop.

Vicky Twomey-Lee

Vicky Twomey-Lee, a techie who has been involved with the Irish Tech Community since 2005, and currently advocates diversity in tech through Coding Grace and PyLadies Dublin. She also co-organises game jams through GameCraft. And with her Maker hat on, she was also the Maker Advocate for Dublin Maker a few years ago. https://www.linkedin.com/in/vickyleeire

Michael Twomey

Michael has been working professionally as a software engineer for over twenty-five years, and has worn many hats over the years in the software industry. In his spare time he helps bring people together through various groups, including Coding Grace and GameCraft. Through co-organizing GameCraft game jams and workshops he's enjoyed teaching people coding and a small bit of electronic engineering. He can always be found tinkering on various electronics projects and is still amazed you can design, order and receive a bunch of circuit boards in the mail in a couple of weeks.

Shipping Quick, Failing Fast

11:30 (30 minutes) · Hall 1A · Talk · Introductory · Product

The biggest waste of product effort often isn't a sloppy feature. It's a polished, well-built one that solves a problem nobody actually had. In this talk, Iz Wright, Product Manager at Gearset, walks through the process behind shipping a customer-validated feature. From uncovering the "real" problem with customers by applying the lessons of Rob Fitzpatrick's The Mom Test to ask better questions, to building a rapid, shareable prototype that lets users react and interact rather than imagine. Iz shows how shipping the smallest possible slice creates space to gather real usage data, iterate fast, and even spot Go-To-Market opportunities hiding in the data.

Iz Wright

With a background as a Product Manager in Tech, Iz has a passion for understanding user needs and translating them into impactful products.

🤔Coming soon

11:30 (30 minutes)

Don’t Let the Bots Win: Taming Web Traffic Without Hurting Real Users

11:30 (30 minutes) · Room 1A · Talk · Intermediate · Security

With automated traffic now surpassing human users and with "bad bots" making up 37% of web traffic, the modern web is increasingly hostile. Traditional security measures like robots.txt are routinely ignored, leaving modern applications highly vulnerable to non-organic traffic surges. This results in outages, increased infrastructure spend, skewed metrics, and decreased confidence from advertising networks. Attendees will learn how to counter this threat by deploying a Web Application Firewall (WAF), while navigating its trade offs such as elevated page load times and false positives that can mistakenly block human users, search engine crawlers, or third-party ad integrations. The session presents a rollout playbook, based on a real world case study from a global media company: a phased, risk-managed approach to introducing WAF safely and reducing bot traffic without disrupting legitimate users or business-critical integrations. This session is aimed at engineers and anyone responsible for the performance, security, or business metrics of a high-traffic website.

Eve Brennan

Eve is a Cloud Engineer IV at a global media company. Her experience spans cloud infrastructure, software engineering, and site reliability engineering. Beyond her core work, Eve organises DevOps Belfast, a meetup group dedicated to fostering knowledge sharing and collaboration between the people building, deploying, and operating modern software. Eve is also a curator for the BelTech conference and an AWS Community Builder.

Getting Shit Done in Two Worlds

11:30 (30 minutes) · Room 1B · Talk · Advanced · Engineering

I build software in two completely different worlds, with the same AI in both. By day I am a principal engineer on a ten-person team, building a distributed AI framework on a graph, wrapped in real governance: human-in-the-loop, guardrails, sign-offs, the lot. By night I run a small consultancy that is me, sometimes one other engineer and a salesperson, shipping monolithic apps with barely any of that. Same models. Same thirty years of habits. Wildly different rules about how far I let the machine run. And I have spent this year paying close attention to what that actually does to the work. The timing is the part I cannot stop chewing on. My day job embraced all of this early and hard, and at the very same time it was scaling up, which meant Agile, governance, sign-offs and ceremony arriving in force. So one world went all-in on the new way of building and wrapped it in heavy process. The other went all-in with almost none. Same paradigm shift, same embrace of it, wildly different amounts of scaffolding around it. And thirty years in I am certain the shift is real: what it means to be a software engineer has genuinely changed, not just sped up, changed. Getting to watch that land in two such different setups at once is the most instructive thing this career has handed me. This is not a "how AI made me faster" talk. We are all faster, and that turned out to be the least interesting part. What is interesting is everything the tool exposed the moment it stopped being the bottleneck: how much governance a piece of work really needs, when guardrails save you and when they are just fear with a process bolted on, and what a big team is genuinely for once one person and a machine can carry a whole app on their own. I will show you the software factory I actually use to get things done: the full-throttle version I run solo, and the stripped-down version that survives inside a governed team. The gap between those two is the clearest picture I have ever had of what engineering at scale really costs, and really buys. I am measuring both sides between now and the conference, and I will put the honest results on the screen, including the ones I do not like. Then I will give you the rule I use to decide how much to trust the machine, and how much rope to give it, depending on which world I am standing in. No sales deck, no tool demo. Just a thirty-year engineer, two very different ways of shipping software, one AI, and what I have learned running it at both extremes. Key takeaways: Why the job of a software engineer has genuinely changed, not just got faster, and what happens when a scaling org embraces that shift and layers Agile, governance and ceremony on top of it at the same time. How to decide how much governance a piece of work actually needs, instead of wrapping everything in the same process by reflex. When guardrails and human-in-the-loop genuinely save you, and when they are just expensive fear. A software factory you can steal: the full version I run solo, and the stripped-down version that survives a governed team. Honest results from running the same AI at both extremes, including what went wrong.

Stephen McCullough

Stephen has over 26 years experience as a polyglot software engineer. During this time he has help lead Belfast Ruby, PyBelfast, Belfast Elixir user groups. He currently works as a principal software engineer building sovereign AI frameworks.

Lunch

12:00 (1 hour)

😏Coming soon

13:00 (30 minutes)

😇Coming soon

13:00 (30 minutes)

Taste in the Age of AI: Designing When Everyone Can Create

13:00 (30 minutes) · Room 1A · Talk · Intermediate · Design

AI has made creating faster, cheaper and more accessible than ever. We can generate interfaces, prototypes, images, code and entire product concepts with a few prompts. But when everyone can create, what separates a useful solution from a convincing one? This talk explores why taste the ability to make informed judgements about what is good, appropriate and worth creating is becoming an increasingly important skill for designers. We’ll look at how designers can use AI more effectively by bringing the skills AI cannot provide on its own: understanding people, framing problems, setting meaningful constraints, making trade-offs and thinking beyond the interface to the wider system. We’ll also explore prompting as a design skill. Rather than treating prompts as magic words, we’ll look at how better questions, context and constraints can lead to better AI outputs and why the quality of an AI generated solution is often limited by the quality of the thinking behind it. The future of design may not be about who can create the most. It may be about who can decide what is worth creating.

Rachael Aluko

Rachael is a product designer and content creator driven by an unwavering passion for crafting meaningful and user-centric experiences. As a lifelong learner, she thrives on exploring new ideas and continually experimenting with design to push boundaries.

Cyberdecks : From scifi to reality

13:00 (10 minutes) · Room 1B · Lightning · Introductory · Wildcard

Cyberdecks: what are they, why are people making them and how far can I get towards making my sci-fi dreams a reality? There's been a trend in some (admittedly niche) areas of the internet for making cyberdecks. These devices started out in 1970s sci-fi novels as personal devices hackers owned, came on screen in 1990s techno-optimist films and now young people online are making their own using Raspberry Pis and hot-glue guns. In my talk I want to briefly explain the internet subculture, show off my progress into making my very own and explain how creative side projects like this can bring use back to what is currently just e-waste. A perfect talk for anyone who reads too much sci-fi and wants to bring creativity back to their side projects.

Dervla O'Brien

Software Engineer for Instil and sometimes volunteer at NI Raspberry Jam. Passionate about arts and technology crossover projects.

OWASP PTK Hands-On: Test the Browser State Your Scanner Cannot See

13:00 (1 hour) · Workshops · Workshop · Intermediate · Security

Modern web applications are authenticated, JavaScript-heavy and stateful. A server response is only the input to the application the user ultimately runs: the browser adds routes, DOM mutations, storage, tokens, loaded components and the exact sequence of actions that reached the state under test. This is a practical, laptop-based workshop using OWASP PenTest Kit (PTK), a browser-native application-security toolkit. Participants will test deliberately vulnerable applications running only on their own machine. They will reproduce a transient SPA weakness, correlate DAST, SAST and IAST evidence, compare it with a repaired control, and then run DAST, SAST, IAST and SCA across one authenticated macro-guided journey. A final request-focused exercise shows why a JWT inside nested JSON is different from a token discovered in cookies or browser storage. We finish by taking the same deterministic journey toward CLI and CI automation. The workshop does not position browser-native testing as a replacement for proxies, source analysis or established scanners. It shows how the browser's live session and runtime state can supply evidence those tools may not observe alone, and how the resulting workflow can complement OWASP ZAP. Participants leave with a repeatable method for connecting a user action to a request or runtime operation, a security finding and a repaired control—not just a list of scanner alerts. ## Format - 60-minute hands-on workshop - Approximately 15 minutes of guided explanation and 40 minutes of exercises - Individual or paired work on attendee laptops - Local, deliberately vulnerable targets only - Prepared screenshots and completed results are available as a catch-up path ## Intended Audience Developers, testers, students, DevOps engineers and AppSec practitioners who work with modern web applications. No previous PTK or professional penetration testing experience is required. Basic familiarity with a browser and web requests is helpful. ## Learning Outcomes By the end, participants will be able to: 1. explain the difference between an HTTP response and live browser state; 2. use DAST, SAST, IAST and SCA as complementary views over one journey; 3. reproduce and validate a transient SPA finding against a repaired control; 4. run an authenticated macro-guided scan without adding an unrelated crawl; 5. inspect and actively test a JWT carried in a nested JSON POST body; and 6. identify how a recorded journey can become a deterministic CLI/CI security check. ## Participant Prerequisites Attendees should bring a laptop with: - Chrome or Edge; - OWASP PTK 9.9.9 or later installed before the workshop; - either Docker Desktop or Node.js 20 or later; - the supplied workshop bundle or pre-pulled container images; and - permission to run local services on ports 3001 and 3080. Firefox is supported as a fallback, but the primary workshop path uses Chrome or Edge. No internet access or cloud account is required during the exercises. ## Safety Boundary All active testing is restricted to the supplied loopback targets. Attendees must not scan public, employer or third-party systems during the workshop.

Denis Podgurskii

Denis Podgurskii is an application security specialist with 15+ years of experience across DAST, SAST, and IAST, focused on making security testing practical for modern web apps and real user flows. He is the OWASP Belfast Chapter Leader and the creator/maintainer of OWASP PTK (PenTest Kit), a browser extension for hands-on AppSec testing (including authenticated sessions and SPAs). Denis also contributes to the wider OWASP ecosystem, including work integrating OWASP PTK into OWASP ZAP workflows.

When Your Software Starts Looking Like Your Org Chart

13:15 (10 minutes) · Room 1B · Lightning · Intermediate · Engineering

We like to think software architecture is driven by technical decisions. In reality, it's often driven by reporting lines, ownership boundaries and incentives. This talk explores how organisational structure quietly shapes software, when that's helpful, when it hurts customers, and how engineers can recognise and challenge it.

Shreya Sahu

Shreya Sahu is a Tech Lead at Monzo, a speaker and writer. She enjoys making complex engineering ideas accessible through stories from real-world software systems and is the founder of The Longer Thought, a publication about systems thinking, incentives and independent judgment.

Less Engine, More Game: Building a Game Engine Inside a Game Engine

13:30 (10 minutes) · Room 1B · Lightning · Intermediate · Engineering

What if limiting a general-purpose game engine could actually make development faster? This talk explores building a smaller, genre-specific engine on top of a broader one, replacing low-level concepts with reusable building blocks that simplify development and speed up iteration. A point-and-click adventure engine built with PlayCanvas React provides the case study, turning generic engine features into rooms, characters, hotspots, dialogue and inventory. PlayCanvas is the demo, but the idea applies equally to engines such as Godot, Unity and Unreal: invest in the abstraction once then spend more time building the game.

Paul Barrett

Software developer based in Belfast. Mainly frontend development & web design but also 3D modelling, animation, game development.

Terminal Panic: Building A Physical Console-Horror Experience, Because I Can

13:45 (30 minutes) · Hall 1A · Talk · Intermediate · Wildcard

I have always loved the chunky tactility of physical buttons, switches, flashing lights and all the trappings of the retro-future promised by classic science fiction, and realised in the arcades of my youth. So I'm building it: a bespoke physical game terminal, part retrogame remake and part movie prop, in an attempt to reimagine one of the most unique and obscure games in the legendary Alien franchise. The fact I can barely hold a soldering iron, never mind design circuits or work a 3D printer, will not scare me off. Join me for a personal project deep-dive that touches on game coding, hardware design, survival horror mechanics, emergent narrative, 3D printing, ‘cassette futurism’ and movie set UI. This is a story of actually finishing a project, building weird things for the love of the process, and the need for creative curiosity now more than ever.

Neil McCallion

Neil McCallion is a Staff Software Engineer at Rapid7, a long-tenured browser-based developer, engineering manager, and occasional community speaker. Neil likes to promote the more creative and experimental side of the Web, from audio-visual art and learning aids to game dev and beyond, while also pushing for better performance, accessibility and inclusion on the platform. Will 'do things' for cake.

From Zero to Container: A Java Quarkus Deep Dive

13:45 (30 minutes) · Hall 1B · Talk · Introductory · Engineering

Java has a reputation problem in the cloud-native world: slow startup, heavy memory footprints, and an inner development loop that hasn't changed in a decade. Quarkus was built to fix all three and in this session, we prove it live. In twenty minutes we go from an empty directory to a running Docker container, using nothing but the Quarkus CLI and the tooling the framework generates for you. We scaffold an application with quarkus create app, explore a dev mode that makes Java feel like a scripting language, and finish by building and running a production-ready container image and no hand-written Dockerfile in sight. But this is a deep dive, not a demo reel. Along the way we unpack the single idea that makes Quarkus different: moving framework work, classpath scanning, dependency injection, configuration parsing, from runtime to build time. Attendees see how that one decision explains Quarkus's startup speed, its memory footprint, its live-coding dev mode, and its path to GraalVM native images. Key learning areas: - Bootstrapping a production-shaped project with the Quarkus CLI and its extension ecosystem - The modern inner loop: live coding, the Dev UI, continuous testing, and Dev Services (zero-config databases via Testcontainers) - Build-time processing: what actually happens under the hood and why it matters - JVM vs. native packaging: honest trade-offs and a clear decision framework for each - Containerising Quarkus applications: the generated Dockerfiles, layered fast-jar packaging, and daemonless image builds What attendees take away: The exact commands, the mental model, and the reference material to go from quarkus create app to a deployed container the same day plus a grounded sense of where Quarkus fits in their stack, and where it doesn't. WHO SHOULD ATTEND Java developers curious about Quarkus or re-evaluating Java for cloud-native workloads. No prior Quarkus experience needed; basic familiarity with Maven and Docker is helpful but certainly not required.

Jason Bell

Jason Bell is a seasoned machine learning practitioner, Java/Clojure developer, author, and strategic advisor with over 18 years of experience bridging theoretical AI concepts and real-world implementation, backed by nearly forty years in software. His book, "Machine Learning: Hands On For Developers and Technical Professionals" (Wiley, 2014 and 2020), is required reading at over 35 universities worldwide including Columbia, NYU, and UC San Diego. Jason's practical approach to machine learning has helped organisations across industries leverage AI to drive growth and competitive advantage. Previously he was section editor for Java Developers Journal, wrote several articles for IBM DeveloperWorks and acts as a AI/ML proposal reviewer for Wiley.

All the data in the world

13:45 (30 minutes) · Room 1A · Talk · Intermediate · Data

You may have heard of OpenStreetMap, a decades-old volunteer effort that seeks to rival with Google Maps. Or does it? This presentation will seek to dispel some common misconceptions, and show how you can use OSM for fun, profit, and even helping in disaster recovery on the other side of the world. Perhaps it will even encourage you to contribute back? This will be an AI-free presentation.

Pablo Brasero Moreno

I am a software engineer with 20+ years of experience and a desire to work towards a better, kinder world for all, now. For most of my career I have worked with web technologies, from London and Belfast, in projects of all sizes and breadths. I don't like talking about myself in the third person.

In Good Taste: How To Build Success Not Slop

13:45 (10 minutes) · Room 1B · Lightning · Introductory · Design

How we design, build and deliver products is evolving… and the roles within that are changing too. Today, everyone has access to tools that can quickly create features that feel real. But fast doesn’t necessarily mean “right”. In this presentation, I’ll share five tangible design tips for those who say, “I’m not a designer,” helping you create successful solutions and ensure your vibe-coded ideas deliver real value for customers, today and tomorrow.

Louise Laughlin

Designer, drawer and dog mum based in Belfast. Passionate about creating meaningful experiences and effective solutions for all through design.

The Weird Creature You Have to Keep Alive Is You: Building a Self-Care Tracker with AWS and an ESP32

14:00 (10 minutes) · Room 1B · Lightning · Introductory · Wildcard

Being a grown up is a lot like caring for a Tamagotchi, except the weird little creature that you have to keep alive is you! Unlike a Tamagotchi, it can be hard to track exactly what you’re doing wrong. In this lightning talk, I’ll run you through how I set out to make this a little easier for myself by combining cloud technologies with an ESP32 microcontroller to create a portable self-care tracker and virtual pet as well as hopefully giving you some inspiration to make your own!

Hephzibah Wilson

Hephzibah Wilson is a Graduate Software Engineer at Hamilton Robson, where she primarily uses Typescript, Node.js, React and AWS Cloud services to develop IoT projects used across the globe to track environmental and occupancy data. She has recently graduated from Ulster University with a MSc in Computer Science. In her spare time, she loves to knit and tend to her herd of Tamagotchis.

Product Market Fit isn't a moment: Designing the systems that get you there

14:15 (10 minutes) · Room 1B · Lightning · Intermediate · Product

Many founders and product managers treat product market fit as a destination - a single moment where customers suddenly arrive and growth takes off. In reality, its rarely an event. It is the outcome of deliberate systems, customer discovery, feedback loops, distribution, experimentation and product decision making. Drawing from experience in building technology products in both start up and enterprise environments, This session explores why product market fit should be viewed as a system rather than a milestone. Attendees will learn practical frameworks for validating ideas and identifying real customer problems, avoiding common product traps and designing products that continuously evolve towards market fit.

Nelson Okpalachukwu

A senior product professional with a background spanning across product management, fintech, insure tech, AI, data platforms and start up innovation. He currently leads enterprise data initiatives at Liberty Mutual, has led start ups across the technology space, and is passionate about building scalable technology solutions that creates real business value, He also holds an MBA from Ulster university

Experiencing first-hand a spicy incident

14:15 (1 hour) · Workshops · Workshop · Introductory · Security

Learn first-hand what it's like to be involved in a critical incident using a group tabletop exercise. Experience it now using an ultra-realistic simulation - or wait until you can experience it for real at your company at 5am.

Joe McKevitt

Its always been about the tech, people and process for me, I love all 3! I am very passionate about topics that help craft great software products, such as Continuous Delivery, DevOps, Test Automation and Architecture/Coding best practices, along with modern leadership and management practices that help grow, nurture, and motivate teams. Over the years, my experience has led me to work within Financial Services, and that experience brought me to cofound Uptime Labs. Our mission is to grow incident response mastery in every company. As a co-founder, we have an opportunity to create a company culture that they always wanted to work for that's passionate about its mission, its customers and the craft of building great reliable products.

Making the Smart Dumb Thing Smart

14:30 (30 minutes) · Hall 1A · Talk · Intermediate · Engineering

I wanted one simple thing: access to the data from my own electricity meter. What followed was a journey through low-level Bluetooth, awkward pairing, undocumented behaviour, failed approaches and a bit of reverse engineering to make a supposedly “smart” device actually useful to me. But the meter is only one example. Our homes are full of devices and services that collect useful data about us while giving us little practical, programmable access to it. This talk is about making one proprietary thing work for me and the questions that journey raised about openness, interoperability and whether the smart things around us really work for the people who use them.

Andrew Fletcher

Andrew is a Senior Software Engineer at Intapp and a lifelong hobbyist, builder and dabbler in technology. Over the past 13 years he’s worked across both the public and private sectors, as an employee and freelancer, building everything from startup products to large government systems. Outside work, he’s always enjoyed experimenting with technology and is finally making more time for the “I must check that out” list that has been growing for far too long.

So, Why Do We Need Quantum Computers?

14:30 (30 minutes) · Hall 1B · Talk · Introductory · Engineering

Quantum computing has gone from a scary research topic to a technology attracting a lot of interest from the wider tech industry. But beyond the hype, what problem are we really trying to solve... and what does quantum computing mean for software developers? This talk is an introduction to quantum computing from a software and engineering perspective. We'll look at what we've achieved so far, what quantum programs actually look like, and what it takes to get a quantum program running on a real quantum computer. The aim isn't to predict exactly when quantum computing will become mainstream, but to help developers understand what quantum computing is, why we might need it, where it could be useful, and what role we as software engineers could play in its future. Key takeaways: 1. Understand the basic ideas behind quantum computing without all the complex maths. 2. See how quantum programs differ from conventional programs and how they interact with classical computers. 3. Explore some of the big technical and practical challenges facing quantum computing. 4. Separate some of the potential applications of quantum computing from the buzz surrounding it. 5. Get an insight into the emerging roles for software developers in a future with quantum computing. No prior knowledge of quantum computing is required!

Jane Moore

Jane Moore is a PhD researcher at Queen's University Belfast specialising in quantum computing. Her research explores how quantum programs are compiled, how the compilation process can be optimised at scale, and how machine learning can be used to analyse and generate quantum programs. Jane is currently finishing her PhD and is looking towards a career in engineering, with interest in emerging technology and early-stage companies.

How to Be a Good Citizen Contributor to Open Source in the Age of Regulation

14:30 (30 minutes) · Room 1A · Talk · Intermediate · Security

Open source runs everything. But in 2026 the ecosystem that sustains it experiences, perhaps, the biggest simultaneous challenges in its history: maintainer burnout, chronic underfunding, regulatory pressure (e.g, from the EU Cyber Resilience Act), an AI-accelerated vulnerability tsunami, and a flood of AI-generated issues and PRs. Open source projects experience "enforced collaboration" that has led companies, researchers, everyone to shove pull requests and demand immediate response from the community, often lacking awareness of the diverse open source governance and contributing norms. This session outlines how people from companies and society can responsibly contribute back to open source while preserving upstream health. It highlights two OpenSSF initiatives. First, a Concise Guide for Upstream Collaboration, developed by the Best Practices WG and aiming to help OSPOs guide employees through security upstream contributions. Second, the deliverables of the Global Cyber Policy WG, including CRA Maintainer Guidance, demonstrating how community developers can establish clear consumption expectations, shielding them from unreasonable compliance pressure. Attendees will leave with a clear understanding of diverse upstream ecosystem operations and how to interact with and responsibly contribute to open source projects we all depend upon.

Roman Zhukov

Roman is a cybersecurity expert, engineer, and leader with 20 years of hands-on experience securing complex systems and products at scale. Currently Principal Architect at Red Hat, he leads open-source security strategy, upstream collaboration, and cross-industry initiatives focused on building trusted ecosystems. He has built and scaled programs across security architecture, threat modeling, secure development, vulnerability management, incident response, and security education - for both engineers and senior leadership. His work spans trusted AI, privacy, compliance, and secure software supply chains. Previously, Roman led Product Security & Privacy for Data Center and AI software at Intel. He is a Security Champion for several open-source projects and an active contributor to working groups under the OpenSSF, Eclipse Foundation, and other global initiatives. He is an official member of CEN/CLC and ETSI standardization groups, contributing to the EU Cyber Resilience Act (CRA).

Agentic AI lessons from my smart home

14:30 (10 minutes) · Room 1B · Lightning · Introductory · AI

A story of what my smart home taught me about agentic AI: Where GenAI genuinely helps to build a smarter home, where it breaks down, the practical lessons that I bring back to my workplace, and where I think AI-powered smart home tech is heading next.

Rory Gallagher

Solutions Engineer at Liberty Information Technology where I've spent 14 years as an engineer and the past 6 years in Liberty's innovation unit. I lead engineering teams exploring emerging technologies, from quantum computing to agentic AI and help to shape which innovations are ready for enterprise adoption.

The Shortcut Tax: What AI Is Costing Your Career Growth

14:45 (10 minutes) · Room 1B · Lightning · Introductory · Career

Before AI, a hard bug meant hours of digging. You read docs, tried things, failed, tried again. That struggle is what built your skill, the same way lifting weights builds muscle. The weight is the struggle. Now AI can hand you the answer in one prompt. Fast, but you skip the workout. You get the fix, not the strength. This talk is about a habit I use to keep growing while still using AI every day: I start the code myself. I write the function signature, sketch the pattern, make the hard calls about how it should work. Then I let AI finish the typing. The thinking happens first. I'll walk through real examples from my own work, including building a notification system in Go, to show what this looks like in practice. I'll also share the trap version of this: what it looks like when someone skips straight to "write me a function that does X" and never builds the muscle for the hard part.

Destiny Amba

Software engineer based in Belfast. Likes building small, practical tools that solve everyday problems, like a personal bus tracker that tells me exactly when to leave home so I'm never too early or too late. Currently learning Go and believes the best way to grow as an engineer is to build the smallest useful thing first, then let the hard parts teach you

Afternoon break

15:00 (30 minutes)

The 'Enlightenment' of LLMs and How to Exploit Them

15:00 (10 minutes) · Room 1B · Lightning · Introductory · Security

Your system prompt, a user's message, and the contents of a scraped webpage all arrive at a language model as one flat stream of tokens. There are tags marking who said what, but models largely ignore them, inferring roles from what text sounds like instead. When tone and tag disagree, it looks like tone wins. This talk walks through why the most interesting attacks don't come from users typing "ignore previous instructions": they come from a Jira ticket, a PR description, or a tool response that quietly tells your agent to do something else. I'll also look at why writing a stern system prompt just isn't enough to protect your agentic system. Key takeaways: - Why LLMs can't distinguish instructions from data. - How indirect prompt injection reaches your agent through the content it retrieves, not necessarily just the input that it's given. - An overview of some practical mitigation strategies.

Corey Duffy

Hi, I'm Corey. I'm a senior software engineer and tech lead, with over a decade of experience building software. These days I'm mostly working on AI products and digital intelligence solutions for enterprise clients, while trying to keep the robots honest. Over the years I've worked across application security automation, fraud prevention, usage-based billing, AI knowledge agents, computer vision projects and more, taking things from early prototype to full-scale systems.

Two Radios and a Terminal: Building a LoRa Command Line

15:30 (30 minutes) · Hall 1A · Talk · Intermediate · Engineering

Off the grid... No Wi-Fi. No cellular. No internet. But the machine is still out there, and we still need to talk to it. In this talk, I'll show you how I built a remote outpost that can be monitored and controlled from miles away using LoRa: a Low-power Radio technology designed for sending small amounts of data over surprisingly long distances...( well, in this example maybe nearer rather than farther) Along the way we'll look at how LoRa actually works, its strengths and limitations, and decisions involved in building software for a connection that is slow, constrained and occasionally unreliable.

Chris Laughlin

Lifelong tinkerer who enjoys exploring new technology, building side projects, solving problems that probably didn’t need solving, and occasionally applying the same over-engineering to his BBQ. Usually happiest when turning a random idea into something that actually works.

You Are Not Netflix

15:30 (30 minutes) · Hall 1B · Talk · Intermediate · Engineering

Somewhere right now, an app with 12 monthly active users has a dedicated K8s cluster. Somewhere else, a "temporary" script is celebrating its 4th birthday in production. This talk will teach you how to avoid both fates. You'll leave knowing when to keep things simple, when complexity is genuinely justified, and how to spot the warning signs of over-engineering and under-engineering before shipping. Our LLM besties have dramatically reduced the time it takes to write code, making design the new bottleneck in software delivery. The most expensive mistakes now happen before anyone opens an IDE. It has never been easier to build the wrong thing at warp speed, whether that's a multi-region failover setup for an app with 12 users or a hacky fix that miraculously becomes the backbone of the entire company. Netflix's architecture is brilliant. It solves Netflix's problems. Most of us have very different problems, and copying their homework won't help. This is a practical framework for designing at the scale you actually operate. We'll dig into why over-engineering and under-engineering are two sides of the same mistake, and walk through questions that tell you whether the simplest design will still be standing in two years. Expect real stories and lessons learned from getting these decisions right, and a few from getting them very wrong. What will I take away? - A cheat sheet for validating that a simple architecture can be extended later, without adding speculative complexity - How to figure out whether a design decision is easy to reverse later, or a one-way door that deserves the whiteboard inquisition - Team habits for making better architecture trade-offs

Lauren Taylor

Lauren is an Engineering Team Lead at Swap, where she leads the Enablement Core team, an infrastructure and platform team focused on helping other engineering teams ship faster and more reliably. Her career spans corporates, startups and scaleups, from government platforms serving millions (including the NHS Covid-19 testing service) to early-stage products, giving her a front-row seat to both good and bad architecture decisions at every scale. She is a long-standing part of the NIDC community, having volunteered as Marketing Lead for 3 years and helped grow the conference from 400 to 750+ attendees. If someone ever ambushed you in the corridor with a microphone, that was probably her. Sorry.

Is this the CVE-nd? Inside the Vulnerability Data Crisis

15:30 (30 minutes) · Room 1A · Talk · Intermediate · Security

This talk explores a growing crisis in the vulnerability intelligence ecosystem. The number of reported CVEs (Common Vulnerabilities and Exposures) keeps rising, while the agencies responsible for tracking them, CISA (Cybersecurity and Infrastructure Security Agency) and the NVD (National Vulnerability Database), are being weakened by political cuts. As a result, traditional vulnerability management tools are quietly failing, and their users don't even know it. At the same time, security researchers are finding it increasingly difficult to disclose vulnerabilities responsibly, exacerbating the long-standing tension at the heart of the CVE programme: balancing the interests of software vendors and researchers. Finally, we look at the latest disruption hitting the community: AI-assisted vulnerability discovery. As automated tooling begins generating CVEs at unprecedented scale, and with hugely variable quality, it is placing even more strain on an already creaking ecosystem. So all of this begs the question: is this the CVE-nd for vulnerability intelligence as we know it? And how do we as developers cope with a increasingly fragmented security space?

Samuel Dynes

Software engineer and security enthusiast who has been working on or around vulnerability management for his entire career. When not sitting in front of a work laptop he’s a big fan of CTF’s, reading about things with no application to real life and a little bit of weightlifting

Debugging Feelings: a neurodiverse engineer learns how emotions and culture are made

15:30 (30 minutes) · Room 1B · Talk · Introductory · Career

In my twenties I developed a crippling fear of flying. What eventually helped wasn't willpower or drugs - it was learning about the theory of constructed emotion, that the racing heart and clammy hands weren't an immutable part of me, but emotions that my brain was constructing from prior experience, and which I could learn to construct differently. That idea turned out to work on far more than aeroplanes. As a neurodiverse engineer - now an engineering manager - I've always found the human layer of work more layered and harder to pin down than the technical one: the emotions you're meant to just get, the unwritten cultural rules, the shared sense of what's "professional" or "fair" that nobody ever writes down. So I did what we do with any undocumented system: I went looking for an explanation, for the source code. This talk is on what I found, drawn from the science of how our own emotions are constructed, how moral foundations theory helps explain why others think differently and how all this comes together as culture. I'll move from managing my own stress before high-stakes moments, to why well-meaning people with different moral instincts end up furious and talking straight past each other, to learning how to read the company or team culture from what emotions are fostered and which ones are forbidden. It's for anyone - neurodivergent or not - who's found the people part of work harder than the code. It's based in real science, and it's given me a model to navigate the work environment. Key takeaways: Emotions as constructed predictions you can reframe — a practical handle on anticipatory stress before demos, incidents, and difficult conversations Why moral disagreements at work lead to deadlock, and how seeing the intuitions underneath makes them navigable rather than infuriating How to read a team as a culture formed of the emotions they display, instead of taking what they say at face value.

Cormac O'Donnell

Cormac is an engineering manager with a PhD in physics and around fifteen years in software, most recently building AI and ML systems before moving back into engineering management. He's long been interested in the contrasts between the technical and human sides of the job - and, as an autistic engineer, in learning to understand emotions, morality and culture deliberately rather than by instinct. This is his first conference talk.

🤗Coming soon

15:30 (1 hour)

Decoding Irish Trad

16:10 (30 minutes) · Hall 1A · Talk · Introductory · Wildcard

How an engineering mindset helped me to understand, appreciate and participate in Irish traditional music sessions Will include a live demo of a playthrough of some tunes and introduction to some technology that will help you to recognise, catalogue and learn tunes to play in next year's Fleadh

Sean McGurk

I am a DevOps Engineer with over 10 years devops experience and over 20 years industry experience. I play Irish Traditional music.

Follow the Twenty Quid: The AI Bill That Doesn't Add Up

16:10 (30 minutes) · Hall 1B · Talk · Introductory · AI

No prompts, no agent architecture, no tooling demo. This is a talk about money. Twenty quid a month. That's what an AI subscription costs, near enough, whether it's ChatGPT, Claude or Cursor. Tens of thousands of pounds for a single chip. Warehouses of them, drawing power like a small city. Somebody is covering the difference, and it isn't me. I went looking for who, and got it wrong twice. Maybe nobody's covering anything, and this simply isn't expensive to run. Except power is only about 1% of what an hour of GPU time costs. The money goes on the chip itself. So the gap is real. Then maybe they're taking the loss on me. Except OpenAI's leaked, FT-verified accounts show serving turns a profit, and the twenty-billion-dollar hole is research. The answer is other users. The 95% who pay nothing, and more surprisingly the quiet payers who barely touch it. The expensive ones are the people in this room running coding agents overnight, and three companies have now said so publicly. That should have been the end of it. Except the labs spent twenty billion a year themselves, so somebody funds them too. Keep pulling and it stops being about software: thirty-eight billion dollars per gigawatt of datacentre, companies buying repurposed jet engines because grid connections take years, and SoftBank selling its entire Nvidia stake to fund a company that hands the money straight back to Nvidia. We have seen most of this film. Netflix burned cash for a decade at £5.99, turned profitable, and only then brought in ads, a password crackdown, and a £12.99 price tag. All three have now appeared in AI, the last of them in April. You'll leave knowing which of the five very different layers of this industry actually makes money, whether you personally are one of the expensive users, and one question worth asking about whatever you're building: what happen if the price of a token doubled tomorrow? Nothing to sell here. Every figure is sourced.

Yuan Zhang

To be update

One Architecture, Any Silo: Proving Patterns Without Naming Victims

16:10 (30 minutes) · Room 1A · Talk · Introductory · Security

Domestic abuse reporting has a data architecture problem. To corroborate a pattern of abuse, systems currently assume the underlying raw data of the victim must be seen by whoever's verifying it. That single assumption forces an impossible trade-off: survivors either stay silent contributing to the dark figure of crime or expose sensitive data to centralised systems that become high-risk targets in their own right. This talk walks through a working Zero-Knowledge Proof architecture built to remove that trade-off entirely one where a statutory authority or third-sector agency can learn that a pattern exists. This can be a perpetrator that has been flagged by multiple independent reports, a threshold crossed, or a count without ever seeing a single name, incident report, or plaintext record. The system works by having each party for example, a police force and a support agency independently commit their records to a cryptographic hash rather than sharing the records themselves. Before that commitment happens, names go through a fuzzy-matching step so that naming variants, like "O'Neill" versus "Oneill," get grouped into the same bucket without anyone comparing raw strings directly. Each party then generates a proof from their commitment, and a verifier who never sees either party's plaintext data checks those proofs and groups them by their public phonetic identifier. When proofs from multiple independent agencies land in the same group, the verifier can say a pattern exists and how many times it's been corroborated, without ever learning a name, date of birth, or case reference. The only thing that crosses back to whoever's watching for patterns is a count and a yes/no flag nothing that could re-identify anyone. Key Takeaways: How Zero-Knowledge Proofs differ practically from Private Set Intersection and Data Clean Rooms, and why PSI's binary yes/no output can't support pattern-counting use cases A working architecture for cross-silo pattern detection where a verifying authority learns only an aggregate signal (a count crossing a threshold) never plaintext records, names, or case files The real engineering challenge of encoding fuzzy, approximate matching (handling naming variants) ahead of a zero-knowledge circuit, and what's involved in eventually moving that logic inside an arithmetic circuit A transferable architectural pattern: any scenario with multiple independent parties needing to corroborate a pattern, without a central party being trusted with raw data

Megan D'Arcy

Combining her background in data engineering with ongoing studies in Applied Cyber Security, Megan brings a unique perspective to data privacy and responsible AI. With a strong foundation in Mathematics and Computer Science from Queen’s University Belfast, her work explores the intersection of machine learning, security, and ethical AI systems. Her final-year project focused on identifying serial killers in the U.S. using statistical models and machine learning. Recognized for her contributions to the tech community, she was awarded the Rising Star Award by Women Who Code in 2024.

We Sped Up Apache Commons' CI Pipeline 3x With an Algorithm From 1969

16:10 (30 minutes) · Room 1B · Talk · Intermediate · Engineering

**Marjia Siddik**PhD Student in Computer Science at Trinity College Dublin

**Samson Oloruntola**Software Engineer at Fidelity Investments

While working as software engineers, we kept watching our CI pipeline crawl to the finish line; one job would drag on forever while three others finished ages ago and just sat there. We got fed up and decided to fix it. Turns out the answer already existed: Longest Processing Time (LPT), a scheduling algorithm from 1969, decades before GitHub Actions was even a thing. We built TestSplit, a CLI tool that profiles your JUnit test suite and uses LPT to split tests across parallel CI jobs so no single job ends up carrying everyone else. We’ll go through why naive splitting, alphabetical order, and round-robin always end up with one overloaded job and a bunch of idle ones, and why LPT's dead simple rule (sort by duration, fill whichever bucket is emptiest) beats it every time. We also implemented MULTIFIT, which uses binary search to obtain a tighter split when LPT's approximation isn't sufficient. We'll get into the actual problems we ran into building both: tests with ordering dependencies that broke LPT's assumptions, floating-point precision bugs in our binary search, and the challenge of parsing Java source files for dependencies without writing a full AST parser. We ran it against Apache Commons Lang, a real open-source repo with 231 test classes and 64,725 tests, and got a 2.24x speedup on test execution and 3.1x over running it sequentially. We'll also be honest about where it falls short: almost 90% of Commons Lang's tests returned a zero duration in the XML output, which messes with scheduling accuracy. If you've ever sat there watching a CI pipeline crawl and thought "there has to be a better way," this is for you. No ML or academic background needed, just tests that take too long. You'll leave with a real mental model for how a 1969 algorithm still beats most naive approaches to a very modern problem, and a working, open-source CLI tool you can point at your own test suite this week to see the difference yourself.

Marjia Siddik

Marjia Siddik is a PhD student in Computer Science at Trinity College Dublin. She was previously a Software Engineer at Fidelity Investments, building and testing tools used by investment analysts.

Samson Oloruntola

Software Engineer at Fidelity Investments and published researcher in software engineering with work on automated refactoring featured by Springer Nature. Interested in building reliable software and tackling complex engineering problems.

Closing & prizes

16:50 (20 minutes)

After-party

18:00 (4 hours)