Parcelling out a program
August 29, 2008 3:56 PM Subscribe
I'm having an incredible amount of trouble parceling out my programming work. For those of you who are coders how do you successfully organize your projects?
I don't know, man, but I'll be watching this thread. Up until now it has been a post-it note with about 10 projects written on it.
Maybe you can go into some detail about "parceling" and "programming work." Just a little about what you're actually doing, which could mean the difference between recommendations of a Palm Pilot vs. Perforce.
posted by rhizome at 4:26 PM on August 29, 2008 [1 favorite]
Maybe you can go into some detail about "parceling" and "programming work." Just a little about what you're actually doing, which could mean the difference between recommendations of a Palm Pilot vs. Perforce.
posted by rhizome at 4:26 PM on August 29, 2008 [1 favorite]
Response by poster: I am working on a video game that is kind of based on creating a racing game based on data analysis of an original work and then making a game around it. Lets say for example that I'm working on a game where images are directly analyzed and a map with gradients is created where your job is to find yourself to the lowest relative color value from the highest. (Note this is not my real idea but has strong similarities, Mostly I saw audiosurf where else can we take this). I keep finding myself getting lost in the data analysis part of it feeling like I am walking in over my head
posted by Rubbstone at 4:50 PM on August 29, 2008
posted by Rubbstone at 4:50 PM on August 29, 2008
Don't get into the mindset of "I don't know how to do this". It's a killer. Research and find a solution.
posted by hungrysquirrels at 4:59 PM on August 29, 2008
posted by hungrysquirrels at 4:59 PM on August 29, 2008
Perforce plus a running daily (manual) log file. And many post-its. And bugzilla.
For the log I have a shortcut in the quicklaunch taskbar to a vanilla windows notepad text file that has .LOG on the first line; one click and you're at the end of the log with current date and time already entered. This turns into a series of text logfiles which I can grep when history digging is needed.
For years I also used spiral notebooks with square boxes drawn in the margin to show to-dos (box checked when done) but don't find them so useful now. Not sure why.
The sccs and the log are the critical bits for me to stay on track. I can work on a problem and if it needs more reflection (or a solution from the morning shower) I can move on and come back to it later. It's really useful to me to be linear sometimes and non-linear at other times; the log and the sccs make that easy.
posted by anadem at 5:29 PM on August 29, 2008
For the log I have a shortcut in the quicklaunch taskbar to a vanilla windows notepad text file that has .LOG on the first line; one click and you're at the end of the log with current date and time already entered. This turns into a series of text logfiles which I can grep when history digging is needed.
For years I also used spiral notebooks with square boxes drawn in the margin to show to-dos (box checked when done) but don't find them so useful now. Not sure why.
The sccs and the log are the critical bits for me to stay on track. I can work on a problem and if it needs more reflection (or a solution from the morning shower) I can move on and come back to it later. It's really useful to me to be linear sometimes and non-linear at other times; the log and the sccs make that easy.
posted by anadem at 5:29 PM on August 29, 2008
Best answer: I like to start by building the minimally functional, smallest unit of work possible that represents all of the various tiers that are interacting. Once this is up and running, I iterate and improve each area and subsystem until it's working.
For your project, you could start with your algorithm, a minimal physics sysem, a rendering engine, user controls, and simple AI. Then start to improve it, by extending this core system.
The risk is that you'll need to throw this away and start over at some point- Fred Brook's mythical man month contains the rule "build one to throw away", because it's almost always the right choice. Read that book if you haven't.
posted by jenkinsEar at 8:19 PM on August 29, 2008
For your project, you could start with your algorithm, a minimal physics sysem, a rendering engine, user controls, and simple AI. Then start to improve it, by extending this core system.
The risk is that you'll need to throw this away and start over at some point- Fred Brook's mythical man month contains the rule "build one to throw away", because it's almost always the right choice. Read that book if you haven't.
posted by jenkinsEar at 8:19 PM on August 29, 2008
Best answer: I may be a dissenting opinion, but I'd suggest considering other VCs besides just Perforce. Mercurial (www.selenic.com/mercurial/), in particular, is free, easy to set up, and easy enough to use / adapt to your workflow that it shouldn't get in the way of your planning. There are a lot of SCSs / VCSs, and you can get really bogged down in the minutiae between them, but Perforce may be too awkward and/or overkill for what you're doing. I've found it to be an impediment to workflow for a large I am involved in. (PM me for details.)
Also, try to keep the sections of your game modular. If you're feeling stuck on the data analysis part for now, just write something that outputs plausible dummy data and work on fleshing out the sections that use the data first. That may help clear up the big picture, and as long as you have clear separation between them, waiting on the analysis itself should be fine.
Finally, some languages are better than others for working on systems where the actual details are still evolving. I'm not going to recommend any particular language, because I don't know enough details of your project (and even perfectly informed people will disagree), but keep it in mind.
Seconding Fred Brooks, etc. on preview.
posted by trouserbat at 8:39 AM on August 30, 2008
Also, try to keep the sections of your game modular. If you're feeling stuck on the data analysis part for now, just write something that outputs plausible dummy data and work on fleshing out the sections that use the data first. That may help clear up the big picture, and as long as you have clear separation between them, waiting on the analysis itself should be fine.
Finally, some languages are better than others for working on systems where the actual details are still evolving. I'm not going to recommend any particular language, because I don't know enough details of your project (and even perfectly informed people will disagree), but keep it in mind.
Seconding Fred Brooks, etc. on preview.
posted by trouserbat at 8:39 AM on August 30, 2008
Best answer: Experience. Read other people code's, see how they break thing. Read books on software design.
Vocabulary. If you don't know what a graph is, you have zero chance of realizing that your code can be refactored as an algorithm over a graph. Read books on algorithms.
Persistence. Apply brain to problem. Push harder.
posted by gmarceau at 10:08 AM on August 30, 2008
Vocabulary. If you don't know what a graph is, you have zero chance of realizing that your code can be refactored as an algorithm over a graph. Read books on algorithms.
Persistence. Apply brain to problem. Push harder.
posted by gmarceau at 10:08 AM on August 30, 2008
Programming a large project successfully takes experience, and the only
way to get the experience is to program a large project.
Programmers can get bogged down in the mechanical details - typing,
editing, compiling, building, testing, version control, issue tracking;
the point is, be aware that if you're not fully comfortable with any of
this, it's going to eat into your time and mindshare. Get comfortable
with this stuff so you can do it quickly without wasting too much time
thinking about it, and save your brain power for where you'll need it.
Schools tend to teach top-down / step-wise refinement style, which is ok
for a beginner, but as you get more experience you'll drift toward
bottom-up. What tools do I need to accomplish the problem? Build the
tools first, and the pieces above will get simpler. Knowing what tools
you'll need is where the experience comes in. Divide and Conquer is the
rule, but there are many different ways to break up a any particular
problem, and some are a lot better than others. These are your important
design decisions.
Some programmers are of the immersion-till-cooked school - they don't want
to code anything until they feel like they understand everything about the
whole problem. This is a serious limitation, because your head can only hold
so much. The single toughest thing about programming is to figure out what
you *don't* need to know at any point in the process, and ignore it.
To put it another way, if you don't understand everything, don't sweat it
- you probably never will. Work on what you do understand, and the other
parts will become clearer. Also, never worry about getting it 100% right
the first time, because again, you probably never will.
The "two things" about programming:
* Don't repeat yourself
* Nothing actually works until proven otherwise, and usually not even then
This is all pretty general, I know. Maybe some of it will help.
Some more concrete advice:
* subversion and trac are good enough for 99% of projects.
* get used to the command line.
posted by and for no one at 12:05 PM on August 30, 2008 [1 favorite]
way to get the experience is to program a large project.
Programmers can get bogged down in the mechanical details - typing,
editing, compiling, building, testing, version control, issue tracking;
the point is, be aware that if you're not fully comfortable with any of
this, it's going to eat into your time and mindshare. Get comfortable
with this stuff so you can do it quickly without wasting too much time
thinking about it, and save your brain power for where you'll need it.
Schools tend to teach top-down / step-wise refinement style, which is ok
for a beginner, but as you get more experience you'll drift toward
bottom-up. What tools do I need to accomplish the problem? Build the
tools first, and the pieces above will get simpler. Knowing what tools
you'll need is where the experience comes in. Divide and Conquer is the
rule, but there are many different ways to break up a any particular
problem, and some are a lot better than others. These are your important
design decisions.
Some programmers are of the immersion-till-cooked school - they don't want
to code anything until they feel like they understand everything about the
whole problem. This is a serious limitation, because your head can only hold
so much. The single toughest thing about programming is to figure out what
you *don't* need to know at any point in the process, and ignore it.
To put it another way, if you don't understand everything, don't sweat it
- you probably never will. Work on what you do understand, and the other
parts will become clearer. Also, never worry about getting it 100% right
the first time, because again, you probably never will.
The "two things" about programming:
* Don't repeat yourself
* Nothing actually works until proven otherwise, and usually not even then
This is all pretty general, I know. Maybe some of it will help.
Some more concrete advice:
* subversion and trac are good enough for 99% of projects.
* get used to the command line.
posted by and for no one at 12:05 PM on August 30, 2008 [1 favorite]
This thread is closed to new comments.
posted by hungrysquirrels at 4:24 PM on August 29, 2008