For the last 2 years now, we have been working on gradually modernizing a large and complex business critical application in Statoil. This 20 year old giant was mainly written in a 4GL (CA Gen), and we wanted to utilize the power of DDD and BDD when rewriting it piece by piece. Now, 2 years later, we find it very facinating to look back at where we came from and where we are now. Of course, much of our code base is in a very different shape, so much easier to understand, work with and change. But also, the entire team culture has transformed. We now have a completely new way of looking at how software is designed and built, how we work together and so on. Our team consisted of about 10 people with great variation in knowledge, preferences and personality. Doing this transformation with them has been a great experience; lots of blood, sweat and tears, lots of fun. In this presentation we’d like to share with you the story including what we've learned and our key takeaways, both the happy parts and the tougher parts, both the technical aspects and the learnings around how to achieve a well functioning DDD team
Decoding Paradoxes: Why are many good ideas in Software Delivery counter-intuitive
How does deploying more frequently improve quality? How does slack time in a team improve reliability? Why should we do it more often if it hurts? These are counter-intuitive concepts that don't make sense at first, and you'll be met with a bewildered stare...