How we think.

J

jfackler

Junior Contributor
Joined
Mar 15, 2003
Messages
393
Location
Cincinnati, Ohio
I'm just back from a meeting with an application server vendor where we spent a great deal of time discussing how programers think. Cognitive theory describes essentially two ways to solve a problem, start with a goal in mind and solve the problem as each piece becomes evident or, study the problem until a valid solution is formulated and then start building the solution. Men and women as groups vary in their process with more women pursuing the former i.e. start first and create the path one crisis at a time, while men tend to have a hard time starting until they've visualized the solution but then moving ahead along the path briskly. I wonder, how do you approach a solution? Do we as programers have a general tendency to approach problems in a similar fashion?


Jon
 
Hmmm,

interesting thought and subject ...

I've been studyin' software engineering for about 5 years. So in theory I should build applications and systems by a calculated system like RAD or IAD or (D)SDM. However when the moment comes and the customer for which the app is made needs it in a hurry, usually people tend to fall back to just building from scratch and see what problems you run up against.

However if the project is major I recommend (and also do myself) using a SE-approach.

Greetz,

D@n.
 
I find that most of the development work behind an idea goes on in the back of my mind, until I have a very good idea how to solve all the potential problems and stumbling blocks that I can conceive of at the beginning. This all happens when I'm bored, when I have a free moment at work etc. And it all happens before I start bringing my ideas to life on a keyboard.

Of course, the unfortunate thing is that I almost inevitably fail to spot all the possible problems that arise during the development process but still, I won't sit down to develop something without already knowing my path pretty well. I guess that puts me firmly in the second category.
 
I'm definitely a plan first, code second kinda guy. I definitely USED to be in the first category, but I found I re-did a LOT of work and I eventually got tired of cutting and pasting and generally making a lot of spaghetti code.

-Ner
 
I start out with a good idea of where to go then get into coding pretty quick. I have always asked myself whether this is the best approach? Up until now I have managed to provide applications quickly so the end users get a good working copy. I then amend thru new versions to include their wish lists.

I would welcome advice on the planning first approach as have never understood how to master/do this?

How can you plan ahead so far then start coding and have thought of everything? I find things crop up as I'm coding which I feel would inhance the app etc that I doubt I would have thought of sitting at a desk with a bit of paper?
 
What I do it have to plan out first, because in my line of work, which is automated testing, I have a prouduct I need to control and get results. So I have to plan out what the controls I need then what the results are that I get back. Then I have to think about the process and then start coding. But lik Hog says, there is only so much you can plan. I find that alot of code I do, I end up doing it as I go along.
 
Back
Top