Creating our own puzzles
In Agile tech circles, we often talk about "slowing down to speed up". For years, I've had a good gut instinct that this is true, but I’ve never untangled that paradox properly. Because slowing down makes you go slower, by definition. What is it about slowing down that paradoxically allows us to go faster?
Yesterday, me and my team did an Escape Room together. We did it all together, and solved the problems collaboratively. It struck me that it would be a good learning opportunity to reflect on whether it was faster to work collectively, or if we'd have been faster if we worked individually, but in parallel.
But something about the analogy with software development didn't feel right. And then it hit me. There's a missing feedback loop with Escape Rooms. The way we solve the puzzles now has absolutely no effect on the difficulty of the next puzzles, or the puzzles that we'll face next time we do an Escape Room.
But in software development, the solutions we write today ARE tomorrow’s puzzles. There’s a feedback loop there. If I solve a puzzle today in a complicated, convoluted way, then tomorrow's puzzle will be complicated and convoluted. If I solve a puzzle today with only partial understanding, then the instructions for tomorrow's puzzle will be incoherent.
The faster we go today, the higher the difficulty level will be tomorrow.
But if, instead, we go slowly and carefully today, then tomorrow’s puzzles will be easy. And easy puzzles don't take long to solve. So we will move faster.
If we take time today to collaborate, to share our understanding, to write clean, easy-to-understand code, with clear abstractions and boundaries, then we will face nice simple problems tomorrow.
And this is why the XP practices are so powerful. Pairing, mobbing, TDD, continuous refactoring etc might look like they slow you down. They probably DO.
But they creates better software, with simpler puzzles for tomorrow. And that allows us to go faster.
Slowing down allows us to go faster.