[OT] How to learn software design

Discussion in 'C++' started by Eric Böse-Wolf, Dec 19, 2009.

  1. I know it is off topic, but maybe someone could
    give me a hint for a good book or few tips on
    learning software design.

    With software design I mean the step from the requirements
    to some sort of software architecture.

    Yours sincerely,

    Eric Böse-Wolf
     
    Eric Böse-Wolf, Dec 19, 2009
    #1
    1. Advertising

  2. Eric Böse-Wolf

    tanix Guest

    In article <>, (Eric =?utf-8?Q?B=C3=B6se-Wolf?=) wrote:
    >I know it is off topic, but maybe someone could
    >give me a hint for a good book or few tips on
    >learning software design.


    Ok, I am going to give you some tips.

    First of all, to learn software design, you'd better study
    what is beauty. Yep, BEAUTY. Believe it or not.

    Then get into music. Believe it or not.

    Music will teach you the structures unlike anything you are
    likely to read in any so calles software book.

    Then, try to understand programming as a system.
    A program is a SYSTEM, a highly complex interactions,
    a higly complex structure, and immensely complex logic.

    Every proggram has millions of logical conditions,
    every one of which must EXACTLY fit with all others.

    Then you learn to state things clear and simple.
    Beauty is forever a simplisity, not complications.

    If you start inventing the complicated ways of doing something,
    watch out, you are in trouble.

    Never EVER ignore even the most minute error.
    It WILL bite you at the end.

    Everything should fit PERFECTLY, 100%.
    You can not ignore anything.

    The program architecture is the crown jewel of programming.
    If you think that optimizing something is where it's at,
    think again. Look at your architecture.

    "The house, built on the sand is BOUND to fall".

    Documentation of your source code and user documenation
    is one of the MOST important things.

    Never EVER ignore errors. Handle ALL exception conditioins,
    conceivable or not.

    If you make your algorithm BASICALLY work,
    but think that some things may NEVER happen,
    think again. Becasue they WILL.

    Document your source code in the most minute detail.
    You'll never regret that one.

    Beyond that, you can take any book you want.

    There are few more things I could tell you.
    But I am not in the mood.

    >With software design I mean the step from the requirements
    >to some sort of software architecture.
    >
    >Yours sincerely,
    >
    >Eric Böse-Wolf


    --
    Programmer's Goldmine collections:

    http://preciseinfo.org

    Tens of thousands of code examples and expert discussions on
    C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
    organized by major topics of language, tools, methods, techniques.
     
    tanix, Dec 19, 2009
    #2
    1. Advertising

  3. (tanix) writes:

    > In article <>,
    > (Eric =?utf-8?Q?B=C3=B6se-Wolf?=) wrote:
    >>I know it is off topic, but maybe someone could
    >>give me a hint for a good book or few tips on
    >>learning software design.

    >


    [lots of sarcasm snipped]

    So it all depends on experience?

    Eric
     
    Eric Böse-Wolf, Dec 19, 2009
    #3
  4. Eric Böse-Wolf

    tanix Guest

    In article <>, (Eric =?utf-8?Q?B=C3=B6se-Wolf?=) wrote:
    >
    > (tanix) writes:
    >
    >> In article <>,
    >> (Eric =?utf-8?Q?B=C3=B6se-Wolf?=) wrote:
    >>>I know it is off topic, but maybe someone could
    >>>give me a hint for a good book or few tips on
    >>>learning software design.

    >>

    >
    >[lots of sarcasm snipped]
    >
    >So it all depends on experience?


    First of all, if you snip the posts like you do,
    you'll never become a good programmer.

    Cunningness is not what programming is all about.

    Secondly, programming is not a craftmanship,
    even though many would claim it is.

    You can not just memorize some buzzwords and hope to ever
    create something that has beauty.

    But it looks like you are a hopeless case.
    Just another ass licker and a cunning man.
    Unfortunately, people like you are the ones that end up writing
    code that ends up being used by thousands if not millions of
    people and all it is is your sadistic pleasure of torturing
    others just because you are miserable yourself
    and do not trust your own being
    and do not believe there is such a thing as a grandior
    of existance.

    Too bad, another sadomasochist is born,
    just like the most of them are already.

    >Eric


    --
    Programmer's Goldmine collections:

    http://preciseinfo.org

    Tens of thousands of code examples and expert discussions on
    C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
    organized by major topics of language, tools, methods, techniques.
     
    tanix, Dec 19, 2009
    #4
  5. Eric Böse-Wolf

    Stefan Ram Guest

    Andy Champ <> writes:
    >Eric Böse-Wolf wrote:
    >>So it all depends on experience?

    >Mostly, yes. Get a job in a good software shop - not something little,


    Some things come together: 0 experience, 1 intelligence (brain power),
    2 education, 3 natural language skills, and 4 personal skills.

    0 experience: but »experience is useless, unless you can learn from it«,
    not everybody can indeed

    1 intelligence: an intelligence above average helps to comprehend
    abstractions, but it should not be too high so as not to get bored
    on the job.

    2 education: a certain knowledge helps: patterns, refactoring,
    architectures like tiers/MVC, unit tests, revision control systems,
    ideas like YAGNI, KISS, DRY, high cohesion/low coupling,
    separation of interfaces from implementations, open/closed-principle,
    dependency inversion, dependency injection, demeters law,
    design by contract, delegation versus inheritance, ...

    3 natual language skills: to communicate with team members,
    superiors, and customers in meetings and in written documents

    4 personal skills: intrapersonal skills: keeping one's poise even
    in difficult situations and being able to focus on the job at hand;
    interpersonal skills: communicating with team members, superiors, and
    customers in a calm and businesslike way, even when under pressure.
     
    Stefan Ram, Dec 19, 2009
    #5
  6. Re: How to learn software design

    On Dec 19, 12:48 pm, (Eric Böse-Wolf) wrote:
    > I know it is off topic, but maybe someone could
    > give me a hint for a good book or few tips on
    > learning software design.
    >
    > With software design I mean the step from the requirements
    > to some sort of software architecture.
    >
    > Yours sincerely,
    >
    > Eric Böse-Wolf


    Hi Eric

    Besides what other said, I want to name a book about (object-oriented)
    software design.
    Recently, I re-read Object Solutions by Grady Booch. It's practical
    and great.

    Regards,
    -- Saeed Amrollahi
     
    Saeed Amrollahi, Dec 19, 2009
    #6
  7. Eric Böse-Wolf

    James Kanze Guest

    Re: How to learn software design

    On Dec 19, 10:00 am, (tanix) wrote:
    > In article <>,
    > (Eric =?utf-8?Q?B=C3=B6se-Wolf?=) wrote:


    > >I know it is off topic, but maybe someone could give me a
    > >hint for a good book or few tips on learning software design.


    > Ok, I am going to give you some tips.


    You've raised an interesting point. And it is at least
    partially true. However...

    > First of all, to learn software design, you'd better study
    > what is beauty. Yep, BEAUTY. Believe it or not.


    Study beauty in what way? I'm not even sure you can study
    beauty, per se, except from a philosophical point of view (what
    is beauty?). Good software engineers do generally have a strong
    sense of beauty, but it's not really something that you can
    study, per se. Except maybe by reading beautiful code (and
    there's not much of that published).

    > Then get into music. Believe it or not.


    > Music will teach you the structures unlike anything you are
    > likely to read in any so calles software book.


    That's an interesting point. I once heard that you should never
    employ a programmer who didn't play a musical instrument.
    Something about the ability to be creative in a structured
    environment.

    I don't think that studying music is really the most rapid way
    of learning software engineering, but I do think that if you
    have a feel for music, it's a good sign that you'll probably be
    able to become a good software engineer. There is some sort of
    a relationship with regards to the most basic skills.

    > Then, try to understand programming as a system.
    > A program is a SYSTEM, a highly complex interactions,
    > a higly complex structure, and immensely complex logic.


    Yes. That's why modern software design borrows heavily from
    architecture (Design Patterns, for example, which were invented
    by an architect).

    > Every proggram has millions of logical conditions,
    > every one of which must EXACTLY fit with all others.


    > Then you learn to state things clear and simple.


    This is an essential point. According to Dijkstra, the two most
    important skills necessary in order to be able to become
    competent are mathematical reasoning and the ability to express
    yourself well in your native language. People who can't write
    clearly and concisely (in their native language---you can't
    always judge by the quality of writing you see here, because
    English might not be the author's native language) will never
    become competent programmers.

    [...]
    > Documentation of your source code and user documenation is one
    > of the MOST important things.


    Good documentation. Written before you write a single line of
    code. Totally aggreed.

    > Never EVER ignore errors. Handle ALL exception conditioins,
    > conceivable or not.


    It's an error to ignore an error:).

    I'm not too sure what your point is. I would say that you must
    define what the program should do for all possible input. (But
    some of those definitions are more or less implicit. I've yet
    to read a design specification which says that the program is
    allowed to stop running if the machine is turned off. Although
    at a higher level---I worked once on a system with a requirement
    that the system continue to perform for up to 48 hours without
    any external power. The system was for the electric company in
    France, and I've always wondered if they didn't know something
    they weren't telling the general public.)

    > If you make your algorithm BASICALLY work, but think that some
    > things may NEVER happen, think again. Becasue they WILL.


    Yah. Someone will turn the machine off.:) (Seriously, if you
    mean what I think you mean, then I agree 100%. Consider all
    possible inputs. In a multithreaded environment, consider all
    possible thread switches.)

    > Document your source code in the most minute detail.
    > You'll never regret that one.


    At the lowest level (and I'm not sure that's what you meant),
    you can easily over-document. There's nothing worse that things
    like:

    ++ i; // increment i
    for ( int i = 0; i < 10; ++ i ) // loop 10 times...

    and such. In practice, within the actual code (as opposed to
    specifying exactly what the function guarantees), I've often
    found the most useful documentation to be that which describes
    what you didn't do: why you didn't use the obvious algorithm
    (e.g. because it would fail in some exotic case).

    But the level of documentation is more what I would consider
    part of the process, and not how to design.

    --
    James Kanze
     
    James Kanze, Dec 19, 2009
    #7
  8. Eric Böse-Wolf

    James Kanze Guest

    Re: How to learn software design

    On Dec 19, 5:03 pm, Andy Champ <> wrote:
    > Eric Böse-Wolf wrote:


    > > So it all depends on experience?


    > Mostly, yes. Get a job in a good software shop - not
    > something little, but one with big teams. 10 years down the
    > line you'll probably have the idea.


    And if you don't know software design, how can you tell if it's
    a good shop. But it's true that the best way to learn software
    design is to first look at some good designs, then try it,
    getting your design and code reviewed by some good designers.

    I don't know any books I'd recommend to cover everything,
    perhaps because the field is too vast to be completely covered
    by any one book. Off hand, I'd suggest Design Patterns, because
    it does talk about design, and the snippets of code in it are
    excellent examples of well designed code (but it doesn't really
    mention any of the architecture issues). In the distant past,
    Robert Martin had an excellent book about creating programs in
    C++, in which he started from the system requirements, and
    worked all the way down to the C++ code. I fear it's a bit too
    dated now, with cloud diagrams (rather than UML) and a C++
    without exceptions, and IIRC, without even templates. (Very few
    compilers supported either at the time the book appeared.)
    Also, because it was a book you could actually lift, the
    projects considered were very small.

    --
    James Kanze
     
    James Kanze, Dec 19, 2009
    #8
  9. Eric Böse-Wolf

    James Kanze Guest

    Re: How to learn software design

    On Dec 19, 7:54 pm, Saeed Amrollahi <> wrote:
    > On Dec 19, 12:48 pm, (Eric Böse-Wolf) wrote:


    > > I know it is off topic, but maybe someone could give me a
    > > hint for a good book or few tips on learning software
    > > design.


    > > With software design I mean the step from the requirements
    > > to some sort of software architecture.


    > Besides what other said, I want to name a book about
    > (object-oriented) software design. Recently, I re-read Object
    > Solutions by Grady Booch. It's practical and great.


    Are there recent editions. I learned OO from it (and yes, it's
    an excellent book), but that was a long time ago. The edition I
    read still used cloud diagrams, and talked about Ada, rather
    than Java, as C++'s concurrent.

    --
    James Kanze
     
    James Kanze, Dec 19, 2009
    #9
  10. Eric Böse-Wolf

    tanix Guest

    In article <>, Andy Champ <> wrote:
    >Eric Böse-Wolf wrote:
    >> [lots of sarcasm snipped]
    >>
    >> So it all depends on experience?
    >>

    >
    >Mostly, yes. Get a job in a good software shop - not something little,
    >but one with big teams. 10 years down the line you'll probably have the
    >idea.


    :--}

    I like that one.
    Yep, I pretty much agree with it.
    After about 10 years, you just START getting an idea about what
    programming is. By that time, you won't be asking THESE kinds of
    questions. You simply won't have time for them.

    As for getting a job with a good software shop, I doubt you have
    a chance if you ask these kinds of questions.

    Just get a job at ANY shop, even the stinkiest one around.
    After all, you won't learn much from PEOPLE in that shop any
    way you cut it. It is primarily a "job security" issue.
    Everyone holds his own "secrets" and never shares it with
    others. Otherwise, he becomes replaceable.

    So, you will mostly learn from the projects and not from people.
    In fact, I did some contract work for the best of the best, and
    the "better" they get, the most rotten and unproductive the
    environment becomes and the more arrogance you see, and less
    of any kind of helping each other to clarify some issues.

    So, get a job at the shittiest outlet you can find,
    and THAT is where you are likely to find the most help when
    you need it.

    :--}

    You will learn via search engines nowadays.
    Very rarely anyone from your own company will be useful to you.
    Most people are only interested in bragging about how great
    they are and doing all they can to discredit and condemn others.
    Again, a job "security" issue, the pittiest and ungliest thing
    in the world in the scheme of things, and the most destructive
    thing you are likely to find on ANY job.

    Good luck.

    >Andy


    --
    Programmer's Goldmine collections:

    http://preciseinfo.org

    Tens of thousands of code examples and expert discussions on
    C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
    organized by major topics of language, tools, methods, techniques.
     
    tanix, Dec 19, 2009
    #10
  11. Eric Böse-Wolf

    tanix Guest

    In article <-berlin.de>, -berlin.de (Stefan Ram) wrote:
    >Andy Champ <> writes:
    >>Eric Böse-Wolf wrote:
    >>>So it all depends on experience?

    >>Mostly, yes. Get a job in a good software shop - not something little,

    >
    > Some things come together: 0 experience, 1 intelligence (brain power),
    > 2 education, 3 natural language skills, and 4 personal skills.
    >
    > 0 experience: but »experience is useless, unless you can learn from it«,
    > not everybody can indeed
    >
    > 1 intelligence: an intelligence above average helps to comprehend
    > abstractions, but it should not be too high so as not to get bored
    > on the job.
    >
    > 2 education: a certain knowledge helps: patterns, refactoring,
    > architectures like tiers/MVC, unit tests, revision control systems,
    > ideas like YAGNI, KISS, DRY, high cohesion/low coupling,
    > separation of interfaces from implementations, open/closed-principle,
    > dependency inversion, dependency injection, demeters law,
    > design by contract, delegation versus inheritance, ...


    But what about Truth?
    It isn't even in the picture?
    Read the end of this reply to get an idea...

    Ok, ok. I AM convinced you are an expert. Hopefully, you will
    be able to solve the real world issues and do understand all the
    buzzwords you spill out here, and, hopefully, you will be able
    to talk to humans and be able to explain things clearly and simply
    so someone, who does not know some issue, can really learn something
    from you and not merely get insulted by your with your "hilier
    than thou" pseudo-explanations, that are nothing more than
    arrogance and insults.

    So...

    I have never noticed you before while looking through archives
    of this group going back several years.

    I just examined the the filters for expers on C++ Goldmine and
    you name was not on it. Now it is. If you want your articles to
    show up on C++ Goldmine, you just need to keep your name as
    Stefan Ram. Your email does not matter.

    The rest is automatic. With the next major revision of collection,
    you will be presented in expert categories no matter that you
    are talking about. There are at least 50 different categories
    of issues on these sites.

    My suggestion is, if you don't mind, is whenever you describe
    something, be as detailed as possible and make sure everything
    is self descriptive more or less, without a need for the
    reader to dig up several levels deeper on different information
    sources in order to be able to understand what you are talking
    about.

    The bottom line is this:

    EVERYTHING you write, from now on, and for a while back already,
    becomes a contribution to the global base on information.
    In this case, on iformation on C++ related issue.

    Now, the thing is, that once you describe some issue in sufficient
    detail, providing all the necessary expanations, you, from then
    on, close that specifi issue for generations to come.

    They do not need to read any other books.
    Because YOUR explanation and coverage totally and completely
    covered that issue.

    I hope you can appreciate what it means.

    Also, be careful as to how you format your articles and interleave
    your text with the text your are following upon.

    Never use tabs.

    Indent things only when necessary.
    There is no need to indent usenet articles in general, unless
    it is absolutely necessary, because it makes it hard to reformat
    your articles to make them easy to be viewed via web.

    On goldmine sites, poor article formatting is fixed automatically.
    But there is a limit to how much things can be changed.
    Specifically, because of the issue of code examples/snippets.
    Because of those, the article formatting can not be drastically
    changed and paragraphds can not be automatically reformatted.
    You have to watch your paragraph formatting.

    Well, anyway, just remember one thing,
    what you write from now on, becomes a global knowledge base
    and your articles could be found on ANY issue within milliseconds,
    no matter what the issue is.

    > 3 natual language skills: to communicate with team members,
    > superiors, and customers in meetings and in written documents
    >
    > 4 personal skills: intrapersonal skills: keeping one's poise even
    > in difficult situations and being able to focus on the job at hand;
    > interpersonal skills: communicating with team members, superiors, and
    > customers in a calm and businesslike way, even when under pressure.


    Well, unfortunately you forgot one lil thing,
    which to me is the biggest thing of it all.
    It is called Truth.

    I don't see it in your equasion.
    How unfortunately.

    You see, you can blabber here all your life,
    and it is all pretty much meaningless,
    unless the most critical criteria in your equasion
    is something called Truth.

    It is not how "nice" you are.
    It is not how much you smile with that plastic smile,
    stuck on your face forever, even when it is utterly unnecessary,
    or even appropriate.
    It does not matter if you know whose arse to lick and how.

    But what DOES matter is Truth.
    The best definition I have heard so far is:

    THAT
    WHICH
    IS

    Simple, ain't it?

    --
    Programmer's Goldmine collections:

    http://preciseinfo.org

    Tens of thousands of code examples and expert discussions on
    C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
    organized by major topics of language, tools, methods, techniques.
     
    tanix, Dec 19, 2009
    #11
  12. Eric Böse-Wolf

    tanix Guest

    Re: How to learn software design

    In article <>, James Kanze <> wrote:
    >On Dec 19, 7:54 pm, Saeed Amrollahi <> wrote:
    >> On Dec 19, 12:48 pm, (Eric B=F6se-Wolf) wrote:

    >
    >> > I know it is off topic, but maybe someone could give me a
    >> > hint for a good book or few tips on learning software
    >> > design.

    >
    >> > With software design I mean the step from the requirements
    >> > to some sort of software architecture.

    >
    >> Besides what other said, I want to name a book about
    >> (object-oriented) software design. Recently, I re-read Object
    >> Solutions by Grady Booch. It's practical and great.

    >
    >Are there recent editions. I learned OO from it (and yes, it's
    >an excellent book), but that was a long time ago. The edition I
    >read still used cloud diagrams, and talked about Ada, rather
    >than Java, as C++'s concurrent.


    A few months ago I read an article on debugging/logging by
    Denis Ritchie (one of creators of C language).

    What a pleasure that was!

    He was presenting his argument regarding debugging vs logging.

    What he said essentiall was this:

    Lots of people tend to use debugging to fix the issues
    with their code. As a result, they tend to get lost in tasty
    local scope issues and can not see the whole picture easily.

    He suggested to use a well designed logging system instead
    of relying on debuggers as much.

    Because a well designed logging system will immediately
    expose your most critical system level issues,
    while debugging will keep you busy for days looking at the
    local scope variables or what have you.

    What an insight.
    It is like listening to 6th symphony of Tchaikovski,
    compared to all the blabber all over the place,
    which is nothing more than a noise in most cases.

    --
    Programmer's Goldmine collections:

    http://preciseinfo.org

    Tens of thousands of code examples and expert discussions on
    C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
    organized by major topics of language, tools, methods, techniques.
     
    tanix, Dec 19, 2009
    #12
  13. Eric Böse-Wolf

    Stefan Ram Guest

    Re: How to learn software design

    James Kanze <> writes:
    >That's an interesting point. I once heard that you should never
    >employ a programmer who didn't play a musical instrument.
    >Something about the ability to be creative in a structured
    >environment.


    http://www.sciencecodex.com/musicia...ir_brains_more_frequently_than_average_people

    But one also has to take into account that people from
    more wealthy families are more likely to learn an instrument,
    so that some of their ability might not be a consequence of
    their musical exercises but of their overall better conditions.
    See also:

    http://scienceblogs.com/cognitivedaily/2009/07/music_participation_doesnt_app.php

    >competent are mathematical reasoning and the ability to express
    >yourself well in your native language. People who can't write
    >clearly and concisely (in their native language---you can't
    >always judge by the quality of writing you see here, because
    >English might not be the author's native language) will never
    >become competent programmers.


    »I've found that some of the best developers of all are
    English majors. They'll often graduate with no programming
    experience at all, and certainly without a clue about the
    difference between DRAM and EPROM.

    But they can write. That's the art of conveying
    information concisely and clearly. Software development
    and writing are both the art of knowing what you're going
    to do, and then lucidly expressing your ideas.«

    http://praisecurseandrecurse.blogspot.com/2007/03/english-majors-as-programmers.html

    >It's an error to ignore an error:).


    If you write a program for your own internal and temporary
    use, sometimes you can code as if an attempt to open a file
    will always succeed and cope with the undefined behavior,
    segmentation fault, or whatever. I have this example in C:

    #include <stdio.h>
    #include <stdlib.h>

    int main( void )
    { size_t buffsize = 16384;
    FILE * source = fopen( "source", "rb" );
    FILE * target = fopen( "target", "wb" );
    unsigned char * buff = malloc( buffsize );
    size_t read = fread( buff, 1, buffsize, source );
    fwrite( buff, read, 1, target );
    return EXIT_SUCCESS; }

    Under my test environment, it indeed did copy correctly the
    short test file I had prepared. So /it did get the job done
    ONCE under these special circumstances/, and if this was all
    that was needed, there is no need to write more than twice the
    code with all run-time error handling.

    (BTW: I am using the above program in my classroom as
    an exercise for the students: The assignment is to add
    all the error handling and resource releasing to it.)

    You just need to know, /when/ to write this »Q&D« style and
    /when not/. When you write code for a library that is to be
    sold to customers, you should better think about possible
    run-time errors and so.
     
    Stefan Ram, Dec 19, 2009
    #13
  14. Eric Böse-Wolf

    Ian Collins Guest

    Re: How to learn software design

    Pete Becker wrote:
    > James Kanze wrote:
    >>
    >> That's an interesting point. I once heard that you should never
    >> employ a programmer who didn't play a musical instrument.
    >> Something about the ability to be creative in a structured
    >> environment.
    >>

    >
    > I used to play a musical instrument, but I've found that the thing
    > that's contributed most to my understanding of programming and program
    > design was law school. That's where I learned to cut through the
    > distractions to see what's really there.


    But didn't that also train you to write arcane and bloated code (form
    one who has seen what patent attorneys can do to a simple idea!)?

    --
    Ian Collins
     
    Ian Collins, Dec 19, 2009
    #14
  15. Eric Böse-Wolf

    Stefan Ram Guest

    (Eric =?utf-8?Q?B=C3=B6se-Wolf?=) writes:
    >I know it is off topic, but maybe someone could
    >give me a hint for a good book or few tips on
    >learning software design.


    http://www.cs.cmu.edu/afs/cs/project/vit/ftp/pdf/intro_softarch.pdf
    http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
    http://www.laputan.org/mud/
    http://www.objectmentor.com/resources/articles/ocp.pdf

    Design Patterns by Gamma, et. al.
    Refactoring by Martin Fowler
    Applying UML and Patterns, 3rd Ed. by Craig Larman

    Structured Systems Analysis (DeMarco)
    Patterns of Enterprise Application Architecture by Fowler
    Object Oriented Software Construction by Bertrand Meyer
    Object Oriented Software Engineering by Ivar Jacobson
    Code Complete, 2nd Ed. by Steve McConnell
    Test-Driven Development by Kent Beck
    The Pragmatic Programmer by Andrew Hunt
    The Mythical Man-Month by Frederick Brooks
    Domain Driven Design by Eric Evans
    Working Effectively with Legacy Code by Michael Feathers
     
    Stefan Ram, Dec 19, 2009
    #15
  16. Eric Böse-Wolf

    Ian Collins Guest

    Re: How to learn software design

    James Kanze wrote:
    > On Dec 19, 10:00 am, (tanix) wrote:
    >> In article <>,
    >> (Eric =?utf-8?Q?B=C3=B6se-Wolf?=) wrote:

    >
    >>> I know it is off topic, but maybe someone could give me a
    >>> hint for a good book or few tips on learning software design.

    >
    >> Ok, I am going to give you some tips.

    >
    > You've raised an interesting point. And it is at least
    > partially true. However...
    >
    >> First of all, to learn software design, you'd better study
    >> what is beauty. Yep, BEAUTY. Believe it or not.

    >
    > Study beauty in what way? I'm not even sure you can study
    > beauty, per se, except from a philosophical point of view (what
    > is beauty?). Good software engineers do generally have a strong
    > sense of beauty, but it's not really something that you can
    > study, per se. Except maybe by reading beautiful code (and
    > there's not much of that published).


    The book "Beautiful Code" is well worth a read.

    http://oreilly.com/catalog/9780596510046

    --
    Ian Collins
     
    Ian Collins, Dec 19, 2009
    #16
  17. Eric Böse-Wolf

    Balog Pal Guest

    Re: How to learn software design

    "Paavo Helde" <>
    > I have hunted down and fixed a race condition error (one of my own,
    > unfortunately) in a multithreaded application which occured only after
    > running approximately 1 hour on a 16-core machine in parallel. I guess for
    > a 2-core machine it would have taken years to exhibit the bug.
    >
    > Indeed, this episode taught me something new about "rare and unimportant
    > events".


    There is a surefire method to produce race condition sraches: arrange a demo
    for the top-level boss or most precious client.
     
    Balog Pal, Dec 19, 2009
    #17
  18. Eric Böse-Wolf

    tanix Guest

    Re: How to learn software design

    In article <Xns9CE6F037A68FFpaavo256@216.196.109.131>, Paavo Helde <> wrote:
    >James Kanze <> wrote in news:02ae8929-f6c1-408f-8efd-
    >:
    >
    >> On Dec 19, 10:00 am, (tanix) wrote:
    >>> If you make your algorithm BASICALLY work, but think that some
    >>> things may NEVER happen, think again. Becasue they WILL.

    >>
    >> Yah. Someone will turn the machine off.:) (Seriously, if you
    >> mean what I think you mean, then I agree 100%. Consider all
    >> possible inputs. In a multithreaded environment, consider all
    >> possible thread switches.)

    >
    >I have hunted down and fixed a race condition error (one of my own,
    >unfortunately) in a multithreaded application which occured only after
    >running approximately 1 hour on a 16-core machine in parallel. I guess for
    >a 2-core machine it would have taken years to exhibit the bug.
    >
    >Indeed, this episode taught me something new about "rare and unimportant
    >events".
    >
    >Paavo


    Well, I'll tell you even better than that.
    One one of my contracts on the global voice messaging system
    with as heavy traffic as you can imagine, I had a client/server
    system. Client was written for windows, server for Unix.

    I ran the load tests.
    It all worked fine for DAYS, millions of messages exchanged,
    and than boom. One funky message had one character wrong...

    Try to fix that one, especially considering you have both parts
    of network traffic, client end and a sever end.

    After that, I am paying much more attention to those things
    that are "impossible to happen".

    --
    Programmer's Goldmine collections:

    http://preciseinfo.org

    Tens of thousands of code examples and expert discussions on
    C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
    organized by major topics of language, tools, methods, techniques.
     
    tanix, Dec 19, 2009
    #18
  19. -berlin.de (Stefan Ram) writes:

    > (Eric =?utf-8?Q?B=C3=B6se-Wolf?=) writes:
    >>I know it is off topic, but maybe someone could
    >>give me a hint for a good book or few tips on
    >>learning software design.

    >
    > http://www.cs.cmu.edu/afs/cs/project/vit/ftp/pdf/intro_softarch.pdf
    > http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
    > http://www.laputan.org/mud/
    > http://www.objectmentor.com/resources/articles/ocp.pdf
    >
    > Design Patterns by Gamma, et. al.
    > Refactoring by Martin Fowler
    > Applying UML and Patterns, 3rd Ed. by Craig Larman
    >
    > Structured Systems Analysis (DeMarco)
    > Patterns of Enterprise Application Architecture by Fowler
    > Object Oriented Software Construction by Bertrand Meyer
    > Object Oriented Software Engineering by Ivar Jacobson
    > Code Complete, 2nd Ed. by Steve McConnell
    > Test-Driven Development by Kent Beck
    > The Pragmatic Programmer by Andrew Hunt
    > The Mythical Man-Month by Frederick Brooks
    > Domain Driven Design by Eric Evans
    > Working Effectively with Legacy Code by Michael Feathers


    Thanks.

    Eric
     
    Eric Böse-Wolf, Dec 19, 2009
    #19
  20. Eric Böse-Wolf

    tanix Guest

    In article <>, Stuart Golodetz <> wrote:
    >tanix wrote:
    >> In article <>, Andy Champ

    > <> wrote:
    >>> Eric Böse-Wolf wrote:
    >>>> [lots of sarcasm snipped]
    >>>>
    >>>> So it all depends on experience?
    >>>>
    >>> Mostly, yes. Get a job in a good software shop - not something little,
    >>> but one with big teams. 10 years down the line you'll probably have the
    >>> idea.

    >>
    >> :--}
    >>
    >> I like that one.
    >> Yep, I pretty much agree with it.
    >> After about 10 years, you just START getting an idea about what
    >> programming is. By that time, you won't be asking THESE kinds of
    >> questions. You simply won't have time for them.
    >>
    >> As for getting a job with a good software shop, I doubt you have
    >> a chance if you ask these kinds of questions.
    >>
    >> Just get a job at ANY shop, even the stinkiest one around.
    >> After all, you won't learn much from PEOPLE in that shop any
    >> way you cut it. It is primarily a "job security" issue.
    >> Everyone holds his own "secrets" and never shares it with
    >> others. Otherwise, he becomes replaceable.

    >
    >There are certainly places where people won't share
    >information/techniques/etc. with others on their team - but they're
    >rarely the best people or the best teams. People at the top of their
    >game generally aren't small-minded - they don't need to be. They know
    >they're not replaceable how ever much they teach other people - and they
    >derive satisfaction from knowing how to do things and being able to
    >communicate that to others. Actually, explaining things to others is
    >often one of the things that helped them become so good. (For what it's
    >worth, I've noticed that the really serious people, who you don't expect
    >to e.g. reply to your emails with a detailed explanation of something,
    >are often the very ones who do.)


    Sounds good. Just like a pipe dream.
    Some kind of virtual sw paradise I might say.

    Unfortunatly, with MY experience in the Silicon Valley,
    doing the contract work on a cream of the crop level
    for the biggest and baddest names in the inststry, such as
    Intel, HP, Sun, SGI (Silicon Graphics), Amdahl, Hal Computers
    (Fujutsu) and few others that is not what I saw.
    BY FAR!

    I don't want to waste my time or your time on pinpoining the
    exact issues as I have not much hope for it. Seen too much
    of that stuff and it is way too consistent.
    Sorry to tell you that.

    >> So, you will mostly learn from the projects and not from people.
    >> In fact, I did some contract work for the best of the best, and
    >> the "better" they get, the most rotten and unproductive the
    >> environment becomes and the more arrogance you see, and less
    >> of any kind of helping each other to clarify some issues.

    >
    >It's certainly true that you often learn more from projects than people
    >- but that's because on a project you're actually *doing* the thing
    >you're trying to learn, which makes it stick much better. On the other
    >hand, there are things that you can learn from other people that are
    >invaluable.


    Well, it is an interesting issue and I do not mind spending a
    few minutes on it.

    Now, to my opinion, being helpful is about one of the most
    critical aspects for ANY project.

    You see, if I have some issue with something of someone elses
    code, it takes a few minutes for them to tell me the tricks,
    issues or provide a solution.

    But it may take me DAYS if I need to dig ALL sorts of things
    on my own. Plus, they can explain the underlying philosophy
    of why they did what they did and what kinds of things it
    may affect, which may take me MONTHS, if not years, if I
    don't know it and have to just keep digging on my own,
    not even suspecting some fine points.

    But what I saw mostly, is pretty abrupt "answers", that are
    not even answers, but the power trips of arrogance and
    "holier than thou" attitude.

    You see, if they spent just a few minutes of their time,
    making sure it is all as clear as a bell, they could have
    haved tens of thousands of dollars for their employer,
    as hidden costs he does not even expect to have.

    And instead, all they are interested is showing you how
    "great" THEY are and how "stoopid" YOU are.
    Sick trip pretty much.
    Interestingly enough, most of them are just morons to me,
    that spent a few years on programming and think they are
    some kind of software kings. But when you look at their
    code, you just want to puke.

    One of the most common things used by these conmen
    is not to document the code so it could be understood
    by others in seconds instead of hours or even days.

    Just look at ANY publishe code.

    I bet you can make it 10 times more readable by simply
    commenting things in place and mentioning the interactions
    with other parts of the overall system, others may not
    even suspect.

    And instead?

    Well, vast majority of code I had to deal with is not
    even commented. A SUPER ego trip of "holier than thou".

    And you are supposed to do what if you have to work with
    that code? To be a mind reader or charvoyant?

    And these suckers do not even care that it costs millions
    to their employees because of all the unnecessary expenses
    on maintaining that code, expanding and extending it, or
    making it bullet proof.

    >> So, get a job at the shittiest outlet you can find,
    >> and THAT is where you are likely to find the most help when
    >> you need it.
    >>
    >> :--}

    >
    >It's an interesting theory - but a bit dubious IMHO :) You'd be much
    >better off getting a job at a place with good people *and* a good
    >information-sharing culture. They exist.


    Well, may be.

    But the guy is a newcomer more or less.
    That is why he is asking this question to begin with.
    So, first of all, he simply has no chance of getting a job
    with "good sw house". They simply don't hire people like that.
    Period.

    He prolly won't pass his first interviewer.

    As far as "they DO exist", sorry, I have to see one first.
    I only recall a couple of people in my entire experience
    that fall into that category, and I worked with hundreds.

    >Regards,
    >Stu
    >
    >> You will learn via search engines nowadays.
    >> Very rarely anyone from your own company will be useful to you.
    >> Most people are only interested in bragging about how great
    >> they are and doing all they can to discredit and condemn others.
    >> Again, a job "security" issue, the pittiest and ungliest thing
    >> in the world in the scheme of things, and the most destructive
    >> thing you are likely to find on ANY job.
    >>
    >> Good luck.
    >>
    >>> Andy

    >>
    >> --
    >> Programmer's Goldmine collections:
    >>
    >> http://preciseinfo.org
    >>
    >> Tens of thousands of code examples and expert discussions on
    >> C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
    >> organized by major topics of language, tools, methods, techniques.


    --
    Programmer's Goldmine collections:

    http://preciseinfo.org

    Tens of thousands of code examples and expert discussions on
    C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
    organized by major topics of language, tools, methods, techniques.
     
    tanix, Dec 19, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Porky Pig Jr
    Replies:
    3
    Views:
    1,056
    Fuzzyman
    May 12, 2004
  2. CoreyWhite
    Replies:
    1
    Views:
    659
    JohnQ
    Mar 31, 2007
  3. John
    Replies:
    0
    Views:
    1,032
  4. John
    Replies:
    0
    Views:
    1,046
  5. Alexander
    Replies:
    20
    Views:
    1,054
    BGB / cr88192
    Sep 11, 2010
Loading...

Share This Page