«

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

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) 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

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.

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.

On Dec 19, 12:48*pm, e...@boese-wolf.eu (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

On Dec 19, 10:00 am, ta...@mongo.net (tanix) wrote:
> In article <7p3lqhFfs...@mid.individual.net>,
> e...@boese-wolf.eu (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

On Dec 19, 5:03 pm, Andy Champ <no....@nospam.invalid> 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

On Dec 19, 7:54 pm, Saeed Amrollahi <amrollahi.sa...@gmail.com> wrote:
> On Dec 19, 12:48 pm, e...@boese-wolf.eu (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

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.