Think More, Code Less

This is the first in what I hope will become a series of posts aimed at beginner and intermediate level web developers. I see it as a venue to share some of the lessons I've learned, and what's worked for me, rather than a definitive development guide.

I've had a quote taped to my door for a few years now, that struck me when I first read it, but didn't really take on any serious meaning until recently.

Code that only you can understand does not make you an advanced coder; code that your grandmother can understand does!
Jeremy Brown - Macromedia Flash MX 2004 ActionScript 2.0 Dictionary

When I initially saw this quote, I took it to mean that I needed to make sure that I wrote clearly and comment things accurately, so that in the future it would be easy to figure out what I had done. Since that time I have slowly come to realize that it means that I need to take the time to think strategically about the code I'm going to write, so that I can keep it as simple and small as possible. All other things being equal, a small amount of code is inherently easier to understand than a large amount of code.

Successfully keeping your codebase as small as possible requires planning up front. Don't get me wrong here, I'm in no way suggesting that one shouldn't prototype. What I'm suggesting is that the prototype should not become the beginning of your codebase. At first glance this might appear to increase your development time, and while this may or may not be true, if done right you will more than make up for this time with ease of maintenance. The key here is doing enough planning to help you steer away from major pitfalls, without boxing yourself in. Your plans, along with any prototypes, should be treated like an artists sketches. They help guide you and prepare you for the final work.

Finally, keep in mind that common sense can be your best asset. I tend to work with Model-Glue for my medium to large scale projects, but I will really think it out before I use it for a small project. It's a question of whether or not the added complexity of a framework will make it easier or more difficult to maintain my project. The answer typically depends on how much I foresee the project growing/changing, and the difficulty of migrating into a framework later if needed. I've even been known to forego CFCs in favor of old school ColdFusion 4 style programming on real simple projects (Typically only if we're talking 1-2 hours of effort and 75 lines of code or less). The point is that you shouldn't be afraid to deviate from "best practices" when the situation warrants, however, when you do it is vitally important to make good notes of what you've done and why you've done it so that the next person that comes along to touch that code, understands what's been done and why.

Labels: Actionscript, Adobe, ColdFusion, Flash, Planning Series

posted by Luis - 0 comments