Because, I play chess

I recently passed a job offer to a friend who gave the offer consideration, but decided that they were better suited with their current direction. Indirectly related, I also found myself two years ago facing the same choice, and two years prior the same exact choice. In my case, I took the offer both times. I was newly married with very little bills and out of college. At that point taking a risk was not a bad choice, as it is now with multiple loans and a baby. Life makes risk harder to swallow.

XKCD 232

The assumption that I blindly jumped into the new jobs however, is way off target. The same approach has played out in my code development strategies. I may make what seems like a risky choice that later, pays off nearly every time. It’s not random. I saw the jobs and code requirements coming; because, I play chess.

When a running-back is given the football, do they run in a straight line? Of course they do, but only when the time is right. More importantly, they have a goal to run at a certain ‘hole’ their offensive line attempts to exploit and then it all depends on skill and luck. Writing code is no different. You know exactly what you want the end result to be and you usually have a good idea of where it begins. To play off the analogy, if your code runs in a straight line, it may achieve your goal, but you’re completely missing the opportunity to make a big play.

Every body knows the second rule of chess (the first being to learn how to play); plan out your next move before you make the previous. Our running back is making his move before he runs into it. In code, you must also think ahead. Planning out your next move is not a short term goal; it’s the long play. When creating a new project, the best code to write is a configuration file. Most developers miss this key step and never notice the problem until they run into it. A configuration file is nothing more than a table of contents for your variables and your variables allow you to juke right and spin.

A configuration file (or files) will hold things like file paths, database settings, environment settings, key integers used for math, etc. Yes, you can hard-code these items in the actual places they will be used. But when the time comes to share your code, or install it on a server, those wonderful straight path entries are your worst nightmare. Plan ahead, use heavily and make a configuration file, or files.

Configuration files hold variables, and as such, variables are the key to agility. I’ve recently been happy to avoid an issue by planning ahead for language in an application. If the code being written has clear text strings alongside logic (sentences the user will read), you might as well sacrifice your queen. This information needs to be in a language file[s]. Do it from the beginning and save yourself (and your queen).

I mentioned putting language information into the code directly, but I really meant templates, not code. Templates are the visual aspects of your projects. Not using templates will actually determine if your application will succeed or fail. The reasoning with that is simple. Every application has layers. From the most generic levels, there are Data layers (Databases|Cache|Flat Files), Business layers (Controllers|Libraries|if|then|for|each) and User Interfaces (forms|buttons|graphics|text). Each layer should be able to be maintained on their own, separate from the others. Mixing these in any way will run you directly into Hackland and Rewriteville.

Imagine a simple to-do application (the most overused demo ever). If you did not use a template, the to-do list rendering would involve a loop that outputs the visuals to a buffer that is displayed when finished. When you want to edit the text of the to-do labels you must now edit the loop. And when the need to make it more performable arrives; edit the loop again. What happens when those two jobs were shared by a designer and a programmer respectively? Uh-oh; conflicts (not to mention the designer would have to understand the loop!).

I don’t want to give away all of my secrets and this post is already long for me, however you can imagine the checklist of items that should be developed in this context. So there is one final rule to understand. Planning for the inevitable, does not mean implementing it. Putting your text in a language file, does not mean you developed a way to toggle languages. Using a template, does not mean there are many developers on the project. The rule, and this is important, goes a little like this; if the effort required to write your code with variables now, impacts you little, but later will impact you greatly at some point, then the risk of never actually implementing that feature is worth it. If the app never goes from English to French, it’s still worth it. And with that, stay variable my friends.