There’s a lot of debate about software engineering methods and paradigms such as test-driven development (TDD), pair programming, agile methods, functional programming, and so on. Which one is the best?
This is how the debate is often framed: it’s about finding the one true method that will deliver the best results and should be used always. Someone will write a post putting forward their favorite method; another person will counter that it won’t work in their specific situation, thus clearly it isn’t good for anything.
I think this misses the mark. The way I think about methods is that you have a toolbox of methods out of which you pick the right tool for the job.
For example, Hillel Wayne recently wrote about What Mob Programming is Bad At. He posited that pairing and mobbing are great for knowledge sharing but they suck for optimization work.
My experience is the same. I’m glad that I have pairing in my toolbox and I can use it when it works well such as when onboarding people to a new project. I don’t think it’s the best choice for every situation. I have other tools for those times.
Code review is another great tool that I use all the time and advocate for, but let’s face it: sometimes all it does is slow you down.
Any tool can be used as a hammer but you do not have to.
Listing all the variables that affect the suitability of a method is left as an exercise for the reader. Here’s a starter:
- Team composition and experience level
- Interpersonal dynamics and power dynamics
- Time and resource constraints
- Type of work: design, feature development, maintaining an existing system, debugging, optimization
- Goal of the work: prototyping, shipping production-quality code, learning, knowledge sharing