Here's a guilty secret of programming: a little debugging is a lot of fun. Granted, too much debugging can be the opposite of fun. Therein lies a mystery: why can't we ever seem to write *just the right amount* of bugs? The discipline tasked with answering these questions, known as Software Engineering has for the past four decades (and a bit) managed to ignore some fundamental facts about programming, such as why a little debugging can be a lot of fun, and more interestingly where bugs come from in the first place. Laurent's talk reveals some dismal truths about this sad state of affairs, but also offers more uplifting suggestions on how we can bring tons of fun back into programming, by developing new skills such as leprechaun hunting and brain debugging.
How can we quickly tell what an application is about? How can we quickly tell what it does? How can we distinguish business concepts from architecture clutter? How can we quickly find the code we want to change? How can we instinctively know where to add code for new features?
A lot of developers have started to believe that hooking Visual Studio up to Azure and pushing code direct from their machines is CD. As much as I hate to say it, it isn't. Continuous delivery has so many more moving parts required to work together. As we discuss concepts such as config management, orchestration, security, monitoring and logging, this talk will help developers realise that continuous delivery is something we need to continually measure, learn and adapt to make us a higher achieving organisation.
How big picture modelling can lead to better software and better companies too.
Traditional requirements gathering and modelling is broken. A simple recipe - bring all the key stakeholders in the same room and build a model of the whole business process, starting from Domain Events, collaboratively - led us to unexpected discoveries and better software too.