A Path Less Taken

I’m old enough to know better. I’m experienced enough to know better. I’m just bright enough to know better. Nonetheless I found myself making the same programming mistakes again this week. I decided that my penance would be to blog about my miss-steps in the hope that you and a future me can learn from my mistakes.

Unit Testing is Good

All of the unit testing nut cases will tell you the same tired mantra. Write the failing test before you write the code. Write just enough test to fail. Write just enough code to pass the failing test. It’s boring, right? Well, boring is what you want! On my latest programming project I started out writing some great unit tests. Then I got anxious. I wanted to see output on the screen. So I stopped writing tests. Bad JJ! My code started to fail on un-tested classes and methods. Since my personal memory stack (my brain) was not focused on those areas it took time and energy to go “now why did I do it that way?” That made debugging a serious chore. If only I had tested those classes and methods when they were fresh in my mind the debugging would have been easier. Also, and this one is worse, as I went back and added needed behaviors to those classes the failing tests would have told me IMMEDIATELY if I had created any un-desirable side effects. The bottom line is this. Test your code as you go. Period!

Defensive Programming is Good

Worse than not testing, I made compromises. I hurried through methods saying to myself “I’ll catch this condition before the code ever reaches this point.” Oh my. Every time we compromise with ourselves we buy trouble. Every time we negotiate with ourselves to write less code we invite pain. Defensive code not only protects itself, it protects other code that has no idea what it’s doing. It stops that code that you wrote at midnight last night from nuking your data set. It protects you from when, even coding defensively, you make a real mistake. It takes more time to code defensively, but it will pay off in the long run. Practice defensive programming and you will sleep well at night!

Short-Cuts are Bad

My current project is a prototype. I’m just working to get a minimal and functioning version of my application up and running to test out my concept. It’s Tracer Code. So I decided to build a simple select statement (switch case in PHP) to act as a pseudo front controller. No big deal, right. WRONG! Before I knew it I needed to process forms, data changes, view changes and AJAX data requests. My “simple” pseudo front controller began to grow into a Christmas tree of branches and conditions that was unmanageable. I finally had to stop and go back to the drawing board. I knew that if the prototype was successful I would have to build a real front controller, but instead of building a minimal one now I decided to take the “easy” shortcut. There is no such thing as a short cut in programming. You will pay for it eventually. It’s always better to write less of a good thing than to mock up something that is too dirty to be useful (or made useful) in a finished solution. Short-cuts are the quickest way to more work in the long run.

None of this is a revelation. None of this is new. Sometimes in the heat of striving to meet a deadline we lose track of the principles and practices of good programming. We forget that we do more now so we can do more (productivity) and do less (debugging) in the future. I learned my lesson again. I hope you can learn from my mistakes.