My Top 5 iRules Development Practices

I've been writing iRules now for about eight years and have found many ways around success along the way. But I've also learned a few things as well, many of which save me a lot of time and frustration on the bigger and more complex iRules.

Know the Problem You are Trying to Solve

I taught a beginning python class last spring and this is the #1 point I drove home in every lesson and in every project. It should be an obvious first step, but eager beavers and mind racers will jump to steps three and four or maybe even 10 before even defining the problem. This is bad news for everyone as they will almost certainly come back to square one frustrated that they built a really cool gizmo that didn't at all line up with the original puzzle that needs solving. Don't move on from step one until the problem is well-defined and further, understood.

Map Out the Logic Before Coding

This one bites me from time to time, but I'm getting better at slowing down my pace enough to do things right. I recommend working through chicken-scratched pseudo-code or Visio diagrams and getting a second set of eyes for validation when possible. Only after you are convinced your logic is sound should you fire up your trusty iRule Editor. Not adhering to this step will more than likely cost you precious cycles reworking code.

Function & Diagnostics First, Optimization Comes Later

When coding, I start with all the events and then begin plugging in features. Some are comfortable writing a 100-line iRule without leaving the canvas, but I prefer to start small, testing along the way. I work on one area of my diagram at a time, using placeholders for any logic I might need for that particular function. I also do my best to avoid combining logic in single lines early so I can log each step. And I like to log. Like crazy amounts of logging. Every event, every variable, every conversion. This makes for a far more successful end-game for me. But that kind of iRule would not pass Colin's performance tests, and I would end up wearing the cone of shame. So after all the functionality is working, that's where I start removing variables, combining logic, looking for optimizations and alternatives.

Test the Negative

What I'm getting at here is not necessarily a literal negative, but testing against the cases your logic solves. If you built code to test if user A has password X, and that works as advertised, great. But what if user B has the wrong password? And what if user C doesn't exist at all? Your logic should account for the obvious negative cases, but also look for the corner cases. It's helpful in this stage to recruit others to test with you as they will not be as familiar with your code and won't make assumptions that are natural to you as the developer.

Comment Liberally

This step is the hardest. Really. Because at the end of all of that, you have a working thing of beauty that you just want to call your wife (mom, dog, empty chair, whatever) and tell her all about. You don't want to document. Ever. But document you must, because it might not be in a day, but when you least expect it, someone is going to have questions about your code, and it's likely even you will have to study it for a while if you don't pepper that code with information. Remember above when I talked about optimization? Yeah, comments aren't compiled into byte code, so you have no excuses to not document the heck out of your iRules. Just do it!