Zen Coding

You wrote the code, now you have to build it, it takes a while before you can see the results. You see the results, bring down the application, write more code and build again. In most serious applications the build time is something considerable. It is the time the machine needs in order to be prepared for your commands. To you it can feel like a short recess, or is it?

The build time is very clear for the machine but it is a very critical time for the coder. Why you say? Lets see. There is a huge tendency for coders to fly away during this time, which can be sometimes rather long (it can include both the code build time and the application startup and initialization time), it seems to be the best time to check the emails again, read a bit more of that article in the open browser, do a few more clicks on that sporadic junk web MMO, try to be cool in the social net or a million other small time suckers that we are all aware of. Why should it matter anyway, the machine is building and there is nothing else for me to do!

Well, there are three main issues with the above scenario:

1 - A shift of attention during this time is a context switch for the brain which can help you forget all the thought process and data you had regarding your problem in your mind. The longer this break away is, the higher the risk and it is quite easy to completely forget what it was you were working on once the application is up for testing.

2 - The time when you stop coding and wait is the best time to focus more on the problem at hand and even if you stop thinking about anything in particular (a zen state), your subconscious will carry on and try to work on the problem from different aspects. This could increase your problem solving quality and over the course of the day, highly reduce the number of times you would need to follow the code/build process for one specific problem. (Providing you with a lot more free time at the end of the day)

3 - Once you are carried away, there is no guarantee that you will come back and test the application once it is up and ready for you, you might spend a lot more time on the other task you started and who knows, maybe even get involved with the article for more than thirty minutes.

So before jumping out to do something else right after you initiated the build process next time, double check and see whether it is going to really be in your benefit and consider the negative effects it can have to your overall development quality. It is not easy but it could be well worth it.

If the problem at hand is too easy and there is absolutely no need for thinking more on it, you can always think about all the things you can do to reduce the lengthy code build time.

(from http://xkcd.com/303/)

The new Hell

We recently thought it was a good time to upgrade the tools and library code that we use. So we went on and upgraded to VS 2010, used the latest version of OGRE 1.8 (un-stable), upgraded almost all other dependent libraries like PhysX, NxOgre, OgreVideo, Theora, ogg, vorbis, ...etc. Recompiled all the ones that had the source code available using VS 2010, quickly fixed the errors related to porting and put all where they belonged and tried to run the game with the old levels we had. Guess what, nothing worked!

Serious crashes and hangs everywhere.

Hmm... it might be related to the new OGRE we thought, maybe because of the way we have changed the use of Threading? Maybe an incompatibility with the new OpenAL? Can it be related to VS 2010? So we started.... we started to try out all different permutations possible with the libraries, ... the new code with the old OGRE, the old code with the new OGRE, the new code with VS 2008, OGRE 1.7, ... OGRE 1.6 ... and any other imaginable configuration, hoping to find the exact module causing the new issues. After almost a week, nothing was found! Strange stuff happened with every change.

Now we are back to the old code base that runs perfect on VS 2008 with all the rusty libraries that are rock solid. Will follow the upgrading of the libraries sometime in the future but this time one by one with proper test suites to run after each change.

Lesson learned: Do not upgrade everything possible over NIGHT!