I wouldn't bother researching all those processes and methodologies.

I believe that if a dozen people pointed to you and yelled "Your pants are on fire!" you'd respond with "I meant to do that and you'll see how smart I am when you want to pay me to set your pants on fire!"

Now, now. Wassercrats is notorious for saying something perfectly sensible in the shortest possible terms. Unfortunately, in English, this means ambiguity. Let's add just a little for tolerances:

I wouldn't agonize over studying and mastering all those processes and methodologies. While they might be useful, they also might not, and they aren't a pre-requisite to writing good code.

I think that's a little closer to his original intent. People can get paralysis from worrying too much about coding in the nebulous Right Way just as easily as they get crap code from Slamming Out Code Without Thinking(R)*.

On the other hand, to quote D.A.R.Y.L., "All knowledge is learning and therefore, good." It's probably worth perusing some of those methodologies, just to see if someone happened to strike gold. Just don't count on it. :-)

* - SOCWT is (not) a registered Service Mark of Micro$uck.

I am not concerned about what is "the right way" as much as what are the more sucessfull ways. Currently, I am lacking any formal tools on software design and would like to add some to my toolbox.

Unfortunately, it is really hard to find any refrences that give an overview of the different design philosophies and methodologies. You almost have to pick a buzzword and learn it. However, I dont want to waste my time learning about a million different design models that I probably will never use since I dont work as a programmer and am not developing for a customer (I am the customer) and dont work with a team of other programmers.

zzSPECTREz

Hey, if it's good enough for *NIX, it's good enough for me.

Hmm.

"C is for UNIX, that's good enough for me"?

--
F o x t r o t U n i f o r m
Found a typo in this node? /msg me
% man 3 strfry

Don't forget the fact that Perl itself is written in C.

Modular design does help. But how do you go about deciding how to begin with your coding. How do you begin the design process? Do you just jump in and start coding? Or do you first think about all the requirements the software is supposed to meet and then sketch out a model? That is kind of what I am getting at. How do you approach the software design process and what tools do you use to do it. Do you like to use UML to model you Obect oriented classes and program flow? What do you and the others here do?

Personaly, In the past I have just thought about the problem briefly and the requirements that the program is to meet. Then I start coding. I begin with usually a main loop or such and that consists of subroutines that have not been created yet. In this way I begin to develop the stucture of the program. Then as I create the subroutines or packages that program uses, I tend to start by handling the error casses. I make sure that the subroutines handle all the error cases first. I dont actually put logic into the subroutines. I just have them die if they do not get called properly or with the incorrect type/kind of parameters and then return with valid or required response. This way I get all the needless design error handled before messing with the more dificult code. Once all the possible error situations are handled and the main loop/section of the program is working properly I begin to code the logic for the subroutines. Up to know, this has worked quite well but is obviously lacking proper time spent on requirements, and design.

I wouldn't bother researching all those processes and methodologies.