Every now and then you hear about a nugget of wisdom which rings true to a part of your life. The latest I've found is the title of this post and comes from the SEAL team who went in and "got" Mr Bin Laden.

When we get a programming problem, as developers we want to rush in and solve it straight away, to get to the good bits. Rush to the finish line so to speak. It can be dangerous though, all too often you don't have all the details and a simple problem on the surface can turn into a horror story pretty quickly once you start unpicking at it. Now you've rushed in to what was a simple problem it might already be too late to easily put it right.

There was a documentary I watched recently about the Navy SEAL team who went in to "take out" Bin Laden. It was interesting to watch as it had EVERYONE on it from the President down. During the strike they landed 2 teams of action men armed to the teeth and they had 30 minute to clear a compound that they expected to be a death trap and somehow get out of there. The most striking part for me though was how they went about it. I sort of thought they were so highly trained they would run in and with some sort of spidey sixth sense avoid any bullets and just blast everything to bits with speed and precision. Instead they took it really steady.

They did it using well practised purposeful drills. Walking between buildings and clearing them one room at a time. Each team member covering the other and improvising when required. There was no sprinting and jumping through windows or running around like a headless chicken, no running through doors assuming everything was clear. They instead purposefully slowed there pace and as a result did an amazing job. There were no heroes running in to clear room single handily, everyone moved as a team.

The mantra they kept repeating was simply "Slow is smooth, smooth is fast".

Your brain wants you to think that speed is what is important to get something done fast, but its not. Not tripping up can do wonders for how fast you get from point A to B, going slowly really helps you avoid anything that might trip you up. Makes sense really. So the next time you are debugging on a live site, take your time just to be sure about your next move. Get into a "known state" (know that room is clear by lobbing in a grenade...well something like that?!?!) and double check everything before jumping into anything to avoid wasting time on red herrings and false leads.

Of late in the office I've been heavily dropping this new mantra. When quoting for work, when designing a new API call, coding up a new class and especially when debugging..."Slow is smooth, smooth is fast". It’s been amazing to see how much more we have got done by not trying to do so quickly. Once you allow yourself (or as the boss I allow others) to take their time our error count reduced and number of red herrings followed during debugging plummet. We are building better software as a result, slow down and get faster, who would have thought it?

It makes sense once you try it. Kanban works the same way, limiting work input increases work through put...weird yet it works. Give it a go and see if it makes a difference to you.