Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Software design -- The confussion of buzzwords

by zzspectrez (Hermit)
on Sep 04, 2004 at 04:10 UTC ( [id://388478]=perlmeditation: print w/replies, xml ) Need Help??

Software design -- The confussion of buzzwords

First, some background. I am not a software developer, nor have I the training or experience to be one. However, I do like computers and have developed a desire to play with computers more then the average joe. I have done coding in 8088 assembly, pascal on both apples and IBM's, and since have found perl as my language of choice.


Over the years, I have developed lots of fun throw-aways but only one application that grew to any considerable size (+1000 lines). Recently, I have began coding more often and have noticed one major roadblock to my development which has really begun surfacing since I have begun playying with OOP. That problem is my process of development. I lack very much structure to my design. I code and fix. Learning from books has taught me understanding of the languages, the control structures, data structures, importance of encapsulation etc... But somehow I have ( missed || been unable to find ) any good knowledge of design. Other then the buzzwords I find on the net and in the bookstores the closest thing I have learned about programing design methods has been limited to Top-Down, Bottom-up, and I briefly remember some book I read that explained flowcharting... (Cant remember the proper symbols though!).

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 doesnt work, or doesnt work well. Then you throw it all away and start again.

So I decided to do some searching to get an idea of the methods and processes used to develop software. There is so much information out there that you quickly get information blurr by the magnitude of buzzwords and design methods. Extreme Programming, RUP, UML, Use Cases, Data Patterns, Agile Software Development, etc....


Software Development Methodologies

Software Development Processes


What I get from the buzzwords...

The steps of development

  1. Software ( Requirements || Specifications )
  2. Design Analysis
  3. Design
  4. Codeing
  5. Testing

My idea of how to proceed

I found a book on jackson structured programming. I think I will read up on this first. Seems more of a design model then design method. In such case, it probably is outdated by UML but appears to be a quick read/learn as compared to UML. Next I guess I should read up on UML since it appears to be a good method to display structure of program as well as structure of classes when you begin doing OOP. Where to go next, Im not sure. Maybee read about Extreme Programming..


Questions

  1. Any sugestions on books that overview the multitude of sofware design methods?
  2. What are you using?
  3. How do you decide how to start development?
  4. How does this change from when you are coding yourself compared to working in teams?
  5. Comments?

zzSPECTREz

Replies are listed 'Best First'.
Re: Software design -- The confussion of buzzwords
by tilly (Archbishop) on Sep 05, 2004 at 01:40 UTC
    My suggestion is that you pick up Code Complete and read it.

    I still think that the first edition was one of the best purchases that I ever made. Be warned, it is big. But even so I've read it several times, and referred back to high points enough to count as having read it more times still.

    I've just purchased the second edition. I haven't read very much of it yet. My impression so far is that it has filled out a couple of "theoretical issues", added basic best practices in object oriented programming, and gives more citations. (Including, importantly, citations up to the present.) Otherwise it is very similar to the old one. If you have a choice, I'd read the second one. But either is useful.

    And one note. A lot of people buy a lot of books because they know that the books are supposed to be very good. And then skim lightly, but never really get around to reading them. Then buy more books.

    Do not do this. (Except with reference books which are not meant to be read.)

    My advice is not to buy a book unless you are going to read it. My way of keeping myself honest is that I work on a small number of books, usually 1-2, and do not buy another book until I have finished my current ones or know that I won't finish. Afterwards I try to digest the book. Any points that particularly struck me I'll look up to be sure that I know where they were and what the evidence for them was.

    Following this advice I don't buy many books. But the value in the ones that I buy is where it belongs - in my head.

      tilly ++

      Code Complete ++
      I backed into programming from engineering and, as such, had no formal education in software development. Feeling really ignorant on the subject (I was, probably still am :^0 ) one of the first things I did was read the first edition cover to cover (took me a while)-- but it was well worth it. I highly recommend it.

      The second book that I would recommend is "Practical Software Maintenance" by T. M. Pigoski. My (limited) experience is that, while most methodology books focus on creating new stuff, most programming revolves around maintaining existing stuff-- apparently maintenance isn't a very sexy topic for authors. I guess that must I disagree with most methodology book authors as I tend to think that knowing how to maintain something well should be a prerequisite for being allowed to design something new.

      The third book that I'd recommend is, errr, hmmm, I don't really have a third recommendation.

      I seriously enjoy book shopping, but yeah, don't buy the books if you aren't going to read them (not that I've read all the books that I've bought, just most of the non-reference ones). Hmmm, htere's (%#@ qwerty keyboards) there's a few that I should re-read.

      --greg

      I have fallen prey to the skim this and that book phenomenon. Start reading one, then get bored and move on to the next. But I agree it is best not to do this

      You are not the first person I have heard speak praises of this book. I think I will have to see if my local bookstore has a copy. Is the book more breadth or depth?

      zzSPECTREz
        You are not the first person I have heard speak praises of this book. I think I will have to see if my local bookstore has a copy. Is the book more breadth or depth?

        It is both more in depth and covers more breadth than virtually any other book you're likely to pick up. Trying to decide which one it does better is pointless.

        Code Complete tries to cover about all "software construction" activities. You might think of this as, "Everything generically involved in coding." It manages to both cover a broad range of topics, yet handles each with detail and specificity. Part of the reason why he is able to do this is the style. He doesn't spend a lot of time arguing - he takes a topic, effectively summarizes what is known, often summarizes some key research (he likes providing key numbers), notes a key point or two, gives an example and then moves on to something else. He also typically leaves you with a list of a half-dozen research papers supporting whatever he claimed.

        The result is both detailed and compact. Which allows him to cover a lot of ground in 862 pages. (Followed by an 18 page bibliography of supporting books, articles, studies, etc.)

        Yet even so he can't cover everything. Which is why he focusses on topics that are generic and cross language. A decade from now, the current copy of Code Complete will still apply even if you're writing in a language that hasn't even been thought of yet. And will still be being cited as a classic. There aren't many programming books that you can say that about.

        You might want to make sure you get the second edition (published June 2004). I have the first edition, but will most likely "upgrade".
      Code Complete v2 is out too. It's quite different from the first edition, but still very good
Re: Software design -- The confussion of buzzwords
by bart (Canon) on Sep 04, 2004 at 19:25 UTC
    Thjere was this little book, only a bit over 100 pages or so, that I liked a lot at the time. It could be that it never got translated into English, it was originally written in Dutch. "Van gestructureerd naar object-geörienteerd programmeren", J.J. Van Amstel Academic Service, (c)1990. Translation of the title into English would have been "from structured to object oriented programming". I can't seem to find any trace of it on internet, I'm quite sure it's out of print.

    Another, thicker, book I recall having borrowed from the library at one time, and which I enjoyed a lot, was a book on "software engineering", from Prentice Hall, translated from English this time. It compared all sorts of methologies and languages. That too seems to have vanished without a trace, but I believe it's the fourth title in this list.

    Both went into great trouble comparing various methodologies, comparing and discussing advantages and disadvantages of each. Too bad it went out of fashion.

Re: Software design -- The confussion of buzzwords
by Wassercrats (Initiate) on Sep 04, 2004 at 04:26 UTC
    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.

      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.

      A reply falls below the community's threshold of quality. You may see it by logging in.
      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.

        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

      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.

      zzSPECTREz
      A reply falls below the community's threshold of quality. You may see it by logging in.
      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.

Re: Software design -- The confussion of buzzwords
by ranjan_jajodia (Monk) on Sep 05, 2004 at 07:53 UTC
    hi zzspectrez,
    1)If you want to dabble in oop the i suggest you go through Ali Bahrami's book titled Object Oriented Programming Concepts which starts from the rationale, basics, various paths that can be taken and all the while continuing with a single example of ATM machine which is very helpful in keeping the things organized.
    2) I have read the above book as well as Software programming by Sommerville and also Jacobson.
    3)Which way to go - object oriented or structured modular and within them which approach to take, all depend on the requirements and constraints. OOP is good but not the medicine of all diseases, sometimes it is the worst choice one can make. Spend as much time as possible in finalizing the requirements. Don't shy away from making prototypes if the project is big enough - the time spent here will pay off in latter stages.
    4) The biggest difference i found is that in teams you got to have clear seperation of duties ( mind you it is not as easy as it sounds), clear interfaces for the various components that are being developed to avoid incompabilities and respect for deadlines as others will be waiting. So make a good estimate of time required before getting started and put 30 % buffer just in case.
    5) Get set go and remember it gets better with time. i work better than i used to 5 months back when i first took up a job
    good luck
Re: Software design -- The confussion of buzzwords
by fireartist (Chaplain) on Sep 06, 2004 at 09:37 UTC
    To add something else into the already excellent replies above, I'd say "read other people's code".

    Pick a small module that you use and think about how you'd implement it. Then look at the source and see how they did it.

    Pick someone you think is a good coder and see if they have anything published on CPAN; read their code.

    Also, some methodologies may only be worth the effort in a larger project. If you want to learn, then think up a larger project you can tackle, or search http://www.sourceforge.net for a project wanting help (working with other coders will particularly help/stretch you).

    At the end of the day,the most important thing is to code, and still enjoy doing it.
Re: Software design -- The confussion of buzzwords
by lwicks (Friar) on Sep 08, 2004 at 11:35 UTC
    zzSPECTREz, I know where you are coming from. Since the days of my CP/M based machine (MicroBee, anyone else have one) Through C64 & PCs I have tried programming on and off.
    I learned bits of code here there and everywhere, but never did much serious coding till discovering Perl. When I started to do more I have found it easy to learn syntax, etc. But that underlying knowledge of how to start and proceed is tricky.

    I have will be buying "Complete Code" now seeing as so many people suggested it.

    One other person suggested Extreme Programming (The "good" XP), I have found it both confusing and usefull. XP is all about the concepts of coding and has helped me get more comfortable with design.

    I also find that a large sheet of paper and a pen help immensely. When I have something to design/code. I tend to get a few large sheets of paper out and try to write/draw/scribble down what needs to happen. I also tend to start building a list of variables/constants/data. When I have a good idea of what needs to happen and the data in play the design tends to come easier. I have found Object oreinted coding tricky to get my head round at first but makes life much easier when you get a grip on it. So definitely read the tutorials here and elsewhere.

    PerlMonks.org is the BEST resource I have found. The posts and the community responses (on the whole) to stupid questions is great!

    So...
    Complete Code - sounds like the "Bible"
    XP - great concepts for managing the process
    PerlMonks - everything else?

    Lance

    Kia Kaha, Kia Toa, Kia Manawanui!
    Be Strong, Be Brave, Be perservering!

      I went down to Barnes and Noble and checked out "Code Complete". It does appear to be the book to buy. It will be my next purchase for sure.

      Another book that I saw/skimmed through, that looks good is UML Distilled. It goes over how to use UML to sketch the design of your objects and codes. I think that this may be the route for diagraming the program/data structure. One thing I allways have found a need for is a way to diagram the structures in a more abstract way then code before actually beginning the coding process..

      zzspectrez
Re: Software design -- The confussion of buzzwords
by KeighleHawk (Scribe) on Sep 08, 2004 at 16:32 UTC
    Based on what you are doing I would suggest the book Refactoring: Improving the Design of Existing Code by Martin Fowler.

    Keep in mind you are not doing this for pay, but for fun. Don't let the "right way" take the fun out of it.

    The thing that most struck me in your statement was your current process causes you to throw it away and and start again. That is rarely a good process. Just because you suddenly find your code cumbersome or inelegent does not make it wasted. It represents your current understanding of the problem. What your code is telling you is you need to clean it up, not throw it out. It is an awfully rare instance I would suggest throwing away working code.

    The problem with the "Software Development Life Cycle" is it assumes at some point in the process you actually know what it is you want. Unfortunatly, the SDLC needs this step to come first and generally it actually comes last.

    One of the really good things to come out of extreme programming is this realization and the attempt to leverage rather than supress this natural process. In your case, Refactoring and Test Driven Development are probably the most useful techniques.

    If you find yourself skimming but not using certain books, don't despair or even be worried. It may well be you are just not yet ready to make use of those techniques. Find another book that seems to "speak to you" more. Save the other books and come back to them later.

    Initially, I would say things like UML and RUP, etc. will be interesting to you not as design tools/methods/processes but more as tracking and documentation tools you use as you go along. Don't worry about designing up front so much as documenting your design as you go. This will not only help you in the proverbial six months later to decipher your code and intentions, it will give you another perspective on your code as you are designing/developing.

    If the class diagram is ugly, your code probably is also. If you find it difficult or impossible to write satisfactory, automated test plans for your code, your code is probably too convoluted and poorly designed.

    Rather than worry so much about adopting a process, just look to aquire new "tools." Learn about the tools and get comfortable with them. Over time, you will likely start naturally drifting towards a more methodical approach just because the new tools make it easier to do so. But learning new tools **AND** a new process at the same time is a bugger and not very fun.

    In all cases, when the programming gets tough, refactor what you have.

Re: Software design -- The confussion of buzzwords
by xdg (Monsignor) on Sep 10, 2004 at 03:58 UTC

    In addition to the many good suggestions above, I would recommend looking at the following two books:

    • The Pragmatic Programmer by Andrew Hunt and David Thomas -- the subtitle is "from journeyman to master". It's a great book on the craft of programming.
    • Agile & Iterative Development: A Manager's Guide -- this contains a good high level overview of the similarities and differences between different software development methodologies

    Beyond this, I've personally been experimenting recently with "test-driven development". While I'm not fully "extreme", the process of writing a test first forces me to think about how a user uses interfaces prior to coding. It's led to some streamlined code and really avoided overbuilding. I suggest doing some research and trying it out.

    As an additional suggestion, unless you have a great local bookstore, I've found O'Reilly's Safari electronic bookshelf to be a great resource for browsing books to get a sense for styles and design methods.

    Best of luck to you

    -xdg

    Code posted by xdg on PerlMonks is public domain. It has no warranties, express or implied. Posted code may not have been tested. Use at your own risk.

Re: Software design -- The confussion of buzzwords
by sandfly (Beadle) on Sep 09, 2004 at 21:20 UTC
    I mostly write unattended jobs that shunt information around a relational database or two. For systems of this type, I generally start with a data model - either a new one, or I sketch out the existing structure. When I have a suitable data model, the processing steps required generally become obvious.

    After that, it is a case of looking for areas of commonality in the process, and factoring these out as subroutines, utility modules and classes.

    I think design becomes more of an issue with interactive systems, because of the potentially large number of states and transitions. I still start with the data model, but I might sketch state transition or process flow diagrams. Then I start coding, pretty much the way you described, blocking out the program structure first, and filling in the subroutines and methods later.

    In my experience, software design doesn't change when a team is involved. But the practice of coding is severely impacted. When you get several people working on related code, individual productivity takes a hit, and you have to get more organised about testing, source code management, release control etc.

Re: Software design -- The confussion of buzzwords
by Rudif (Hermit) on Sep 07, 2004 at 22:12 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://388478]
Approved by Albannach
Front-paged by Courage
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others browsing the Monastery: (7)
As of 2024-03-19 08:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found