It’s been about 10 years since I got my Agile training from James Grenning and started an Agile Pilot with my team. Right from the start I was super keen and got people practicing TDD and Pair Programming even though I didn’t really know if that effort would pay off. I just knew we had lots of problems with the old way so I wanted to embrace the new.
So I’d run my own little sessions with the broader team in Sydney sharing Agile concepts and ideas. Giving us a chance to discuss things and keep learning long after James had left. But often I would present new ideas and a few people in the group would respond “oh of course, that’s just common sense”. Initially I thought it was great as they were embracing these ideas as valuable even though it was not what we were doing before. But after a while I started to get frustrated because they we’re not really listening. If some small part of a concept fit nicely with their “common sense” then they took that on and ignored the rest.
I will also include some warning smells along the way. Things that will give hint your design is not testable.
1. Dependency Injection
This is one of the first things you’ll learn in doing TDD. It doesn’t matter if you’re doing London Style or Chicago Style you will eventually hit cases where you need to swap out the real item. It may be because that real object would touch the file system, a database or a network. Or it may be because it forms a convenient seam between your code and something more complex.
Smell: Singletons and classes that new their dependencies.
Early on when trying to apply Agile methods to software development I found a lot of the challenges were in the area of software testing. Not just because a lot more automated testing was being done, but because requirements would shift and change rapidly. Many levels of rapid feedback needed to be in place to ensure the development didn’t misstep for too long.
I started exploring more places a focus on testing and quality could be applied. And that led me on a journey earlier and earlier in the development timeline.