James has worked in software since the 1990s when TDD was something you studied but never did, pipelines were for carrying oil and "Agile" and "Lean" were words used for describing athletes. James worked for 9 years in a startup where he learned the hard way about CI, CD and splitting the monolith. In 2015 he started a new life as a consultant, spending 4 wonderfully happy years at ThoughtWorks. In July 2019, he started a new adventure at Codurance where he is a champion of software excellence through solving the organisational problems.
Quantum computers are coming. When they arrive, which is probably sooner than you think, all of our classical encryption algorithms are dead. Shor's algorithm was formulated by Peter Shor in 1994. By using some fairly simple number theory, a bit of computationally complex (for a classical computer) modular exponentiation and some quantum magic, Shor's algorithm can efficiently factorise numbers. The quantum magic is weird, very weird. By using the Quantum Fourier Transform a quantum computer can exploit the interference pattern generated in parallel universes to discover the periodicity of modular exponentiation without actually calculating successive powers. So what can we do when RSA dies and what should we do now? BB84 is provably secure and also relies on quantum mechanics, specifically the polarisation of light photons. I will demonstrate BB84 as well as some classical algorithms that we can be using now that are quantum safe. The talk includes an explanation of how Shor works, a demonstration of an implementation of Shor using Q#, an explanation of BB84 and classical quantum safe algorithms and a lot of fun in the process.
Scheduled on Saturday from 16:20 to 17:10 in Room 7
Last year at Devoxx Ukraine I presented Agile is a Dirty Word for the first time. Since then it has become my most consistently successful talk with its mixture of dry humour, real life anecdotes and tales of dysfunctional business that every audience can relate to. When I first gave that talk it was intended as a bit of a lament against all the bad implementations of Agile that I've come across in my career as a consultant and I touched upon a couple of techniques that I was experimenting with at the time. A year on and I have put into practice some of my own suggested techniques and I've been involved in some stunningly successful transformation work. This talk is not just a lament against dysfunction (although there will be a bit of that still) but it is now a playbook of practical steps that can be used to effect lasting change in any organisation.
Scheduled on Friday from 18:40 to 19:30 in Room 5
We are often asked as software professionals to estimate, often with a laughable level of precision, the time for a whole product at the very time that we have the least idea how long it could possibly take. Unsurprisingly these estimates don't turn out to be very accurate. Why do people think they need these estimates? What value do they think they get from them? In my entire 20+ year career in software delivery I have rarely seen estimates used positively, for example to help inform a business plan. I have only ever seen them used negatively, as a kind of post hoc pseudo contract that the development team inevitably broke. In this talk I will explain what I think are the only times that estimation is justified and what you can do to prevent getting forced into a binding contract that you not only didn't sign but that you didn't realise even existed.
Scheduled on Friday from 14:45 to 15:00 in Room 5