Code Preplanning

[madgernader]

Well, this is strictly an opinion based question, but what do you guys prefer to do when laying out a program, what features it will use, and how you will go about accomplishing those tasks.

For example, in the class I'm in for programming the teacher has us make flowcharts showing what each I/O is and how that affects the program in its path of running, And personally I'm not a fan of it, and so I was wondering what you guys like and what you think works so others can see and try it out...

[Bob]

=)

That is a great question, and you are right to question your teacher’s motives with the flow charts. They are just there now so the teacher understands that you understand what you are doing and how things fit together, Lego style. One of my teacher’s had me doing that for a long time too.

Ever since I stepped out of my larvae stage and started working for folks there was a huge disconnect between my thoughts (concept driven) and their actions (experience?), mainly in the planning stage. Here I was out of high school with little experience and lots of the "concepts" jammed into my mind, so there was a steep learning curve that made me feel like an ass. I would plan out what I was asked to do to a level that took all of the fun out of a project. And over the years I was shown, and exposed to, the extremes. One place loved the fact that I planned every statement and drove me into the ground with that sort of work - I quit b/c it was too stressful. The second place didn’t understand what it meant to plan so when I came in and tried to change the way they lived and worked - what they called "tried and true" - I was considered an evil doer and shunned. They pressured me out the door, and I was again able to quit with an open heart, realizing that they had again stressed me out with their spur of the moment and drop everything attitude that seems to permeate these types of people.

Currently I work at a middle ground. I don’t know if you have read it yet, but there is a book from , called , in which he explains his stance on specs and how he believes they should be done. He was a project manager at Microsoft back in the 90's for the excel team and has since moved onto his own group, Fog creek software. He has published so don’t worry too much about having to buy the book now, although it was a great read. I can recommend a few others if you are interested.






The place I'm working currently has some serious specs - more the technical version than the Spolsky vision, but they have some merit to them as well. Personally I have adapted the Spolsky type specs into what I have been shown at work, and I don't think that I have experienced such great results as when I first submitted a spec to a user who had been wondering what they were going to receive. If you are interested in seeing what a spec that I have written looks like is the best example as of yet.

For what its worth, and hindsight being 20/20 of course, when I was working back in the day on my mod, I can see that there were a number of issues rooted in the fact that we had a flimsy design document. We had no idea what we were doing, and tried extremely hard to keep our heads out of the clouds, but for one reason or another they always drifted. If I could do it differently I would have spec’d out every aspect of our game, and there is a good chance that it would have come together better in the long run.

[madgernader]

Yea I see what you mean, This is the first year my school has had a class on programming, so our teacher is pretty much learning as we are, so its good to know its not solely his idea to use flowcharts so often...

Anyway I just read Joel Spolskys writings on specs and I can really see how they can help keep things organized and flowing well. Now I realize I should probably rough out one of those for my mod, because direction is something we really have been lacking...

Well, thanks for the quick response, and it helped a lot, as usual, you rock.

[Bob]

You are very welcome. thank you.