No, this is not me continuing to wax philosophical on the merits of spending time out in the real world with real people doing real things. That was yesterday’s post, and I feel I’ve more than exhausted the topic for the time being. Rather, today’s discussion is a delightful inversion of my typical advocacy for doing actual work in favor of simply thinking about doing so. That’s right, today I’ll be talking about the importance of planning, specifically with regards to large software projects. Yes, it’s a horse that’s been beaten to death, but it’s one that I haven’t had the personal pleasure of bludgeoning quite yet, so you’ll have to bear with me.
In past posts, I’ve treated as a talking point the fact that it’s very easy to get caught up in the planning phases of a project. There’s a certain human instinct that calls for utter perfection in everything (at least if you’re obsessive-compulsive like I am), and it’s a simple matter to get caught up in trying to make everything function flawlessly from a theoretical standpoint before even attempting to get your hands dirty. I’ve gotten hung up on planning complicated tile-layering procedures, exact control schemata, the high-level game mechanics; you name it, and I’ve easily sunk hours into planning for it. Now, I wouldn’t call any of that time wasted, because my notes and scattered thoughts will eventually form the basis for some crucial element of the final product, but I can’t say this was time entirely well-spent.
It wasn’t until I started really getting into the nitty-gritty of programming everything that I began to appreciate the end result of my planning, though. As much time as I’ve spend dilly-dallying around and putting off actually making something that other people can see and experience, the planning that’s gone into Atma so far has helped me tremendously with speeding through establishing the basic structure of the game. Planning out class structures and interactions ahead of time means very little time spent fiddling with and being confused by labyrinthine spaghetti-code monstrosities (naturally, I’m exaggerating for effect here, but the odds of assembling such a creation are surprisingly high without a clear plan from the get-go), or, conversely, throwing together something that is functional and easily understandable, but too simple to accommodate extension without requiring a complete re-vamp.
Planning is something that I feel is most effectively done on regular paper, with a regular pencil (so you can erase bad ideas and proceed to pretend they never existed — none of that “scratch it out and keep writing” nonsense that pen users are so fond of). For some reason, it just seems more natural to me to write out my ideas and have them all filed away in a notebook that I can reference off to the side while using the computer. It could be for the same reason people still read actual books despite the Kindle’s best efforts to digitize the entire process; it could be that I’m simply better able to focus when I step away from my laptop, and, by extension, the gluttonous, all-consuming maw of distraction that is the Internet. Whatever the case may be, clutching a sheet of paper in my hands when I sit down in front of my lovely, back-lit monitor and start pecking away at the keys gives me a feeling of direction and purpose.
If for no other reason than this sense of direction, a bit of planning is a powerful thing. Planning isn’t necessarily about knowing exactly what the end product of your efforts will be, but what it’s always good for is giving some definition to the individual steps required for you to create that product. Planning at its most basic is about establishing small, achievable goals. Instead of saying “I want to make a game” and being stuck at that goal for the better part of an eternity, the entire thing becomes much more approachable when you break it down into discrete portions, like the creation of a Sprite class which can represent any arbitrary game entity. Planning is a way of explaining to yourself exactly what your long-term goals call for in the short run, and if you work with other people, it takes on the even more essential role of translating one person’s vision into something that other people can participate in and help create.
There’s most certainly a balance to strike, here. If you spend all your time planning, it’s time that you’re not spending doing anything, and worse, you can build a terrible habit of procrastination out of an insistence on planning out all details of a situation. On the other hand, diving right into something without giving any consideration to how you’ll approach it is always a risky venture, and such recklessness more often than not leads you to wallow around in confusion for far longer than you would have spent simply meditating on your course of action for a few brief moments. I personally err towards the former extremity, but I’ve already confessed to this. Hopefully as I continue Atma’s development, the lessons I’m learning will become a more deeply ingrained component of my work ethic, and knowing what and when to plan will become a more natural part of my thought process.
I’ll suffix this discussion with a pithy observation: if I spend even five minutes outlining what talking points I’ll cover in any particular blog post, I easily save myself half an hour of time while writing that post. This is, regrettably, one of those posts that I — for whatever reason — did not plan out ahead of time, and the end result is a significant amount of wasted time; I don’t feel too guilty, since my programming today was fairly productive, but it seems a significant point to me that such a minor amount of planning can save so much effort in the long run. And really, this is what’s at the heart of today’s post — a little planning goes a long way.