In the ReadyTalk nerd book club, we just wrapped up reading and discussing Continuous Delivery by Dave Farley and Jez Humble.

You know, there are those tech books you read that you hope to gain some useful insights from or some knowledge that will ultimately make you a better programmer. Then there are those books you read that you hope will fundamentally change how you think about programming and engineering software. Continuous Delivery falls into that second category.

For this book, we roughly 50 percent of our software engineers participate. Among them, there were a few who had historically been skeptics of the benefits of things like continuous integration, unit testing and automation. It was refreshing to see the assortment in the room, from the Linux ninjas to the server engineer,s to the automation engineers; it was a room full of powerhouse thinkers. I could tell this book would generate a lot of great dialog but I had no idea of the movement it would cause.

The book took roughly 12 weeks to complete, and when all was said and done, the non-believers had become believers. The engineers were going back to the drawing board to figure out how to shift course on current projects and deliver functionality in a more continuous model. In some cases this caused the end product to be delivered a bit later than initially expected, but the result ultimately would be smoother and done with more confidence because of smaller, less risky deployments. Several weeks ago, I overheard one of our engineers who had been a skeptic say during a engineer whiteboard session "I'm really drinking this TDD kool-aid. I think that is how we should approach designing the server components for this project."  That was music to my ears!

People are interesting creatures. We're the most complex machines on the planet, and we learn best through experience. There are some things that need to come from within a team, and concepts like TDD and continuous delivery are among them. To really get a team to buy in to it, they've got to have skin in the game and they've got to figure out as a team that it's the right thing to do. The pain along the way is minuscule when the outcome is ultimately success.

So, how have your engineering teams embraced concepts like these? Are they topics of discussion or myths? I'd love to hear your thoughts and experiences about this!

Jason Collins (aka JC) is the VP of Engineering at ReadyTalk and the self-appointed Chief Happiness Officer. He's been either writing code or managing engineers for nearly 15 years and has a passion for technology and agile development practices. The happiness of the engineering team is his top priority and he can usually be found wearing a ReadyTalk cape and the infamous "idea helmet" around the office to help keep people entertained. When he's not hanging out with his work family, he's at home with his wife and four boys doing all sorts of geeky things, like playing video games and watching campy Sci-Fi and Action flicks.