Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Re: Software design -- The confussion of buzzwords

by Wassercrats
on Sep 04, 2004 at 04:26 UTC ( #388480=note: print w/replies, xml ) Need Help??

in reply to Software design -- The confussion of buzzwords

You said "The problem with coding then fixing is that many times you are half way through coding your program when you realize that the way you have designed code that doesn't work, or doesn't work well."

Wouldn't using a more modular design with smaller parts help? I wouldn't bother researching all those processes and methodologies. The large number of them tell me that which is best is a matter of opinion, and I'm sure it says somewhere that you could use a combination. You could also invent your own. Learning all that would just waste my time. Just teach me all the Perl functions and maybe some good modules, and I'll be satisfied.

  • Comment on Re: Software design -- The confussion of buzzwords

Replies are listed 'Best First'.
Re^2: Software design -- The confussion of buzzwords
by chromatic (Archbishop) on Sep 04, 2004 at 05:33 UTC
    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.

      More like "I don't feel the pain and you'll want to pay me to cook your ribs once I'm fully ignited."
        I guess that the best method is knowing that you have to finish the job, even if you have to do it all again , and again. Am I talking about being paid?

        So, when you are sure that you are going to finish it. You start thinking ahead.

        Your structure is going to appear after thinking about the piles of data that you are going to collect before starting the code.

        Then, even when you are actually structuring everything, you keep on fearing that all your good code is not going to take you through the easy way to the end. So, you start asking someone that might have done something similar. There comes the different ways of approaching your analysis.

        The conservative way is getting the most close to your way of working. The most innovative one is tryied when you start getting tired of your daily routine. More or less...

        _`(___)' __________________________
Re^2: Software design -- The confussion of buzzwords
by xCodexWarriorx (Acolyte) on Sep 04, 2004 at 05:22 UTC
    I definitely agree with the whole 'modular design with smaller parts' bit.

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


      "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.
Re^2: Software design -- The confussion of buzzwords
by zzspectrez (Hermit) on Sep 05, 2004 at 04:14 UTC

    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.

      What I do varies from routine to routine within a script, and from script to script. I'm satisfied being loose like that. Squeezing every script into a formula would add monotony to an already monotonous job. But I'm not very experienced. Maybe I'd notice or develop some patterns if I was.
Re^2: Software design -- The confussion of buzzwords
by chaoticset (Chaplain) on Sep 11, 2004 at 16:05 UTC
    I wouldn't bother researching all those processes and methodologies.
    It's true, research is a useless process. The only thing gained from it is knowledge.

    You are what you think.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://388480]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (3)
As of 2018-05-22 00:54 GMT
Find Nodes?
    Voting Booth?