Rock climbing software problems

This one goes to Brian who got me back to climbing after all these years.

I used to rock climb a lot. It’s one of the few sports I cherished for the longest time before I ran out of time to focus on it. There are striking similarities between rock climbing and writing software and analytical thinking to reduce problems to its bare essence. Yes, I’ve climbed the Cathedral Peak and Royal Arches with lots of unexpected happenings, inspite of the training.

This is me on Royal Arches way over the pine trees:

When you think about writing software to solve complex problems, there are analogous things you do in rock climbing:

• When you observe rock climbers, they make it look easy, but it’s because of tremendous training and perseverance (and falling securely a lot!).
• The Campus Board is one of the coolest things to strengthen your fingers. So is your keyboard, if you use the backspace key as much as I do, to not hesitate to delete the code you wrote. Third time’s a charm, for sure.
• Most adept climbers don’t climb before they scope the wall. What this means is you plan ahead as to where you are likely to place your fingers, feet, chin, etc., before you climb the wall. In other words, you don’t start writing code until you’ve worked out the kinks on paper. It’s all too tempting, but then you get stuck on mismatched hand positions and you fall and are forced to climb all over again, especially when you are tired. And trust me, it hurts.
• If you are sport climbing or bouldering you typically have someone else to either belay or spot you. It means there’s someone to guide you and protect you when you make a stupid mistake that could cost your life. In software engineering that means XP or TDD. Don’t write code without someone else to tell you about all the wrong design and implementation decisions that you are making.
• Most important of all is that, if you think you are a hero when you climb, you will fall. The best way to solve problems is to check your ego out. You solve problems, because they are there and are waiting to be solved. You will be a hero for sure, after you have topped off, but not before or during.

The interesting thing about rock climbing is the anticipation of the unexpected and weathering the real-meal-deal. The rocks in Yosemite are just different from the nicely made hand-holds in the gym. You are in the element and all the training (testing) that you did in the gym (lab) doesn’t completely apply in the real world.

Why this blog? Well, we just introduced Mu Studio for testing the unexpected. The thing is, we’ve spent the last few years providing you with ready-to-go protocol fuzzing for a wide range of protocols all of which are IPv6-ready where appropriate. But you have scenarios that are specific to you, the rock that you want to climb. Either a multi-protocol-interaction or extensions to protocols, you wanted to be able to harness our fuzzing engine to your needs.

We listened.

With Mu Studio, you can now convert any packet capture that you have and auto generate the mutations to fuzz on the interaction. With our really advanced protocol engine, it doesn’t matter if the pcap is for VoIP, IPTV or some application (like REST, SOAP, etc). You can fuzz application interactions as easily as fuzzing ARP. It’s stateful, does both one-arm testing as well test DPI, firewalls, routers and proxies and it generates the same set of mutations that our native implementation gives you.

Auto generating test cases has never been easier! Test for the unexpected and you can be a hero too. And remember about the rocks at Yosemite. You can never quite completely prepare for the unexpected, but you can certainly train to overcome them.