Design before Code

        There's this image of the ultimate programmer that no doubt, at least, will flash through the newbie programmers mind. He's a genius, no doubt wearing glasses, he writes code by himself, he doesn't write bugs--ever, and he doesn't plan before coding (after all the code he excrements exceed the value of John Carmack's code). Now the first quality surely helps at programming but the rest are superfluous or just plain wrong. No one cares if you wear glasses or not. EVERYONE makes bugs, its natural because we're human beings and we make mistakes. And (depending on the size of the project) no one-I repeat- NO ONE can code all alone or start coding before designing a good bit of the structure.

Today I'll talk about the designing part of programming. I'm working on a dice game for Android and during the early stages of the game I made a class that you send an int Array (int[]) and it will return the highest score possible of that group of dice. While I was designing the class, it occurred to me that it was the perfect situation to use a Final Class. There was no instance dependency anywhere in the class and all the methods could have easily been static. BUT!, being the lazy person that I am I decided to make a regular class that used variables to keep track of the number of dice face values i.e. numOf1 = 3 implies that in the array there are 3 ones. During the development I kept having to change a lot of the code of the other classes to accommodate for the shortcomings of the class. For example, I forgot that since I used 1 instance the state of the variables were never reset to 0 after the class calculated the score of an Array. Little mistakes like these forced to make the class Final and all the methods in it static, which looking at it now makes the whole project A LOT easier.

What Am I driving at here? Well basically, all that hardship could have been avoided if instead of being lazy I stopped coding for a moment and thought about the future of the project. But I didn't. I love to code and while I was coding I was in the ZONE. You know how it is. Its like a vice. You feel omnipotent. I did and I didn't want to stop to think about the design of the structure. And it cost me. Getting in the zone is often regarded as when you get the most work done or the most important work done. Sometimes getting out of the zone and into design mode can help a lot more.

My shout out for this post goes to Joel Polsky who works at Fog Creek Software. He's very a very smart down to earth man who's blog post give a lot of advice based on a good bit of experience. This blog post should speak for him better than I ever will be able to ;-) Until next time. Follow me on twitter @tytdfn to send me suggestions or questions.