A couple of weeks ago, me and my former colleague Anita Kvamme, gave a presentation at the ExploreDDD conference in Denver. I must admit there was quite a few butterflies upfront, rising from questions in my head like “will there be anyone interested in listening to us?”, “will we be able to convey our thoughts in a meaningful way”, “will I stumble and fall?” etc, but when I was finally standing there on stage, telling everyone what I’m really passionate about, it was so much fun – and extremely energizing! ? People came up and asked lots of questions afterwards, wanting to discuss further – very motivating!
ExploreDDD is the first conference on Domain Driven Design in the US, and it was a spectacular event. Many of the world-leading experts in software development where present, such as Eric Evans, Vaughn Vernon, Ward Cunningham, Julie Lerman among others, and just being there together with these people, and being able to discuss all kinds of software design issues with them and all the other smart people was AWESOME. The atmosphere was really friendly and “homely” – we all felt like best friends, joined by our common passion. And you know, riding a party bus crammed with 30 speakers, including all the IT superstars, with disco lights in the floor and a dancing pole … nothing short of a once-in-a-lifetime experience ?
Our presentation was called “From legacy chaos to the promised land of DDD”, a case study from a previous project where we had a team of developers accustomed to coding in an old-fashioned way to start coding using Domain-Driven Design and Behaviour Driven Development. Given that this was an IT conference, the audience was familiar with these concepts, but for those of you who aren’t, here’s a quick introduction:
Domain Driven Design is about how you can make the design of your software match your mental model of the domain you are addressing with your solution. When doing this right, new features are easily implemented, almost like magic ?
Behaviour Driven Development is a way of exploring what your system should do, by discussing examples. The examples drive the implementation of new features, and they are also coded as feature tests, ensuring that any existing functionality isn’t broken when adding a new feature or fixing a bug.
Add the two of these together, and you get…well, Matt put it quite well:
The DDD + BDD approach to software development maximizes the software developers’ understanding of the business, enables change and growth of the software in sync with the business model, and increases the likelihood of users being happy with using the software. This is what we do in Headshed, and with our new team we can do even more of it. 🙂
After this conference I feel even more confident that we are on the right track. We know what it takes to create great software, and we have the competence to do so! To our customer, clients, tenants and users, this means better usability, more flexibility, easier implementation and a closer connection to the continuing development of our product.