… but not all the time
I saw this in a job posting the other day, describing the work environment at the company:
We pair a lot, but not all the time. We test a lot, but not all the time. The key is being able to explain your practices with rational argument.
I love this. There are practices like testing that I hold in high regard, but nothing should be done all the time. As the posting says, “the key is being able to explain your practices with rational argument.”
Can you explain why you do something like TDD? That’s probably easy for you. But can you explain when you shouldn’t use that practice? That’s a little harder to do, and maybe because you’re holding onto some ideal that says you should test all the time or have 100% test coverage.
For every idea or practice that you find valuable, you should also be able to explain when it doesn’t apply. If you can’t explain when not to do it, I would say that you don’t really understand when and why you should use it.
We have a similar philosophy where I work as well. We believe in having default patterns and practices, but we encourage people to apply critical thought to modify those patterns and practices to fit individual scenarios.
In other words, we like to strongly adhere to PRINCIPLES [short feedback cycles, reduce cost of change] rather than PRACTICES [TDD, pairing, etc].
This works well for us, and I’d venture that it works well for EdgeCase/New Context too.
However, there is some risk. It’s sometimes hard to tell if you’re eschewing something because you truly have a good reason, or just because you THINK you have a good reason. For example, the team says “on this project, we decided not to TDD because [the tests are slow|take too long to write|etc]”. In some cases, those reasons are just manifestations of the team’s immaturity with a process or skill.
My point is, the easier it is to do and the more comfortable a team is with avoiding recommended practices, the greater the risk that those practices are being avoided for the wrong reasons.
In other words, when you explain when something doesn’t apply, make sure you’ve identified the TRUE reason! I find the “5 whys” technique is very illuminating when making these decisions!
Sure there’s some risk, but that’s where you need to have good people. If you have A players, you can trust them to make the right decision, and their talent will shine as you set them free. If you have a mediocre team, they might not succeed because they need the extra guidance and structure, so you pretty much guarantee that you’re going to remain in mediocrity. This is just one example of why we need to get the wrong people off the bus and get the right people on the bus in the right seats.