How to design OO systems...

[Ilja Preuss]

In a thread some time ago, I stated that "good OO-systems doen't try to 'model the real world'". The obvious reaction was: "Then, how *do* you design OO systems? Where do you get your classes from, if not from the conceptual (analysis) model?"
Well, I didn't answer that question until today, but I thought about it nearly daily. There are several problems associated with answering the question: For example, it is a rather complex one. Bigger minds than me have written whole books about it (and many of them have failed nevertheless, in my humble opinion). And most importantly, I am still struggling with the problem myself - every time I think something along the lines of "now you've groked it!", it doesn't take me much more than half a year to let me think "dear me, what were you doing???" ...
So I finally decided to *not* answer that question all at once, but to try to do so incrementally and interactively. That is, the successfulness of this thread will heavily depend on your participation! Hopefully we all will learn at least *something* along the way...
Acknowledgement: Many of my current thoughts are heavily influenced by the ideas of Agile Software Development, especially Extreme Programming and the works of Robert C. Martin.
[ April 27, 2003: Message edited by: Ilja Preuss ]

[Ilja Preuss]

The first thing I think we have to speak about is: *why* do we design at all? The computer doesn't care about the design, after all.
What do you think? What are the goals of a "good design"?
[ April 27, 2003: Message edited by: Ilja Preuss ]

[Anonymous]

Analysis comes before design, if you analyse, i.e. think, the next stage - design, just comes out as obvious consequence.

[Jayadev Pulaparty]

The first thing I think we have to speak about is: *why* do we design at all? The computer doesn't care about the design, after all.

To save money I think this is the bottom line... to cut down the future costs of modifying (extending the functionality by keeping it as open-ended as possible, fine tuning the performance, easy maintainability, etc.) the software by delivering a qualify piece of job. Improper designs may result in a lot of re-work (if the flaws are identified at a later stage).

Analysis comes before design, if you analyse, i.e. think, the next stage - design, just comes out as obvious consequence.

I'm a little unclear here. When you say analysis, is it requirement analysis, or some other thing. Please clarify. If it is requirement analysis, then i don't think design will be a consequence of that. Analysis is what needs to be done (capture of requirements) and design is how to do it in a smart way (by classes, etc.), IMO. BTW, i guess the GRASP stuff (general responsibility assignment sofware patterns) will help in evolution of classes in the design phase from the analysis phase. Don't know the details about this stuff though.

[Ilja Preuss]

Let's define "Analysis" and "Design" here:
Analysis, for me, is solely about the problem. In analysis you think about what the system will need to do and how it will get embedded into its context.
As soon as you start thinking about how the solution will look like, how the system will do what it needs to do, you are thinking about the design.
In my experience, there is no direct connection between the structure of the problem domain and the structure of the solution. Even if you fully understand the former, it might be far from obvious what the latter should look like.
For example, just because your system has different types of users doing different things to the system, it's far from obvious that you need different subclasses of an abstract User class. It could be as appropriate to let the User class have a role attribute - if you will need a User class at all.
So, why does it matter which solution to use? It seems as if both subclassing and using the role attribute would be more or less substitutable, doesn't it? (Suppose that the role of a user doesn't change.)

[Anonymous]

I have never formally designed. Just coded and refractored (and only many years later had come to know how it is being called).
I came to programmyng from other field, so I by habit, use the definitions of analysis - desintegration to small pieces, synthesis - building from them (designing?).
I think it is not very different in OOAD. OK, I just looked for formal definition:

Analysis.
The part of the software development process whose primary purpose is to formulate a model of the problem domain.

Well, it doesn't contradict to anything. To me modelling is discrimination the samll bricks.
I think design is the overburden/overkill and is really needed only for very complicated cases/teams (teams with a great patience) and still I participated in heavy projects without much of it.

[Ilja Preuss]

Originally posted by Jayadev Pulaparty:
To save money I think this is the bottom line... to cut down the future costs of modifying (extending the functionality by keeping it as open-ended as possible, fine tuning the performance, easy maintainability, etc.) the software by delivering a qualify piece of job. Improper designs may result in a lot of re-work (if the flaws are identified at a later stage).

Extendability and maintainability are certainly very strong forces to design, yes! Are there more forces coming to mind?

[Anonymous]

I am sorry, I shall just add up/continue without reading your answers.
How I understood analysis corresponds to its general definition, took the first dictionary from the shelf (there was no "analysis"):
"Analyse - divide up a thing into the parts of which it is made..."
Isn't it how humans initiate thinking, is it how it is impossible of thinking without first distinguishing/recognizing/discriminating elements, words?

[Ilja Preuss]

Originally posted by Tom�s S�oPaulo:
I have never formally designed. Just coded and refractored (and only many years later had come to know how it is being called).
[...]
I think design is the overburden/overkill and is really needed only for very complicated cases/teams (teams with a great patience) and still I participated in heavy projects without much of it.

I agree with you that what some people call "Big Up Front Design" (that is, designing on paper for months before actually writing a line of code) is most probably overkill for most projects (and actually has killed some).
I disagree, though, that just because you aren't doing BDUF, you aren't doing design at all. Refactoring, for example, *is* a design activity. So is deciding about the existance or even the name of a class. In my humble opinion, you can't code without doing design - and the less design you do up front, the more you need to do while coding.
See Martin Fowlers article "Is Design Dead?"

[Chris Mathews]

Originally posted by Tom�s S�oPaulo:
I think design is the overburden/overkill and is really needed only for very complicated cases/teams (teams with a great patience) and still I participated in heavy projects without much of it.

By refactoring your work you are in fact "designing". I take it what you really meant to say is that up-front design is not needed for most projects. That itself can/should be an entirely separate argument.

[Chris Mathews]

You beat me to the punch Ilja...

Originally posted by Ilja Preuss:

Extendability and maintainability are certainly very strong forces to design, yes! Are there more forces coming to mind?

Those two points alone cover most of the things I worry about. I guess I would add one more: risk management. We design because not to design will introduce a higher degree of risk to our projects. In other words, we design because we are afraid to not design.
However, like you said above... it is not an all or nothing game. No matter what you are doing there is no way to get completely away from some form of designing. Even if you are just hacking out code you still need to choose class names, method names, etc... these decisions are what designing is all about.

[Jayadev Pulaparty]

Originally posted by Ilja Preuss:

I agree with you that what some people call "Big Up Front Design" (that is, designing on paper for months before actually writing a line of code) is most probably overkill for most projects (and actually has killed some).

I think this is what the WaterFall model of the Unified Process for software development talks about. People say that, after a lot of research, trying to design "everything" before going for coding will be dangerous. That is why the unified process suggests the Iterative and incremental approach wherein we have a waterfall model (design, implement, test, etc.) at the level of each iteration. The question of testing comes into picture as the result of each iteration is expected to be an executable (though incomplete) version of the final system we are going to develop. But also mentioned is that the design and implementation of the high risk areas(properly identified before-hand) should be done in the early iterations.

[aadhi agathi]

The most important need for design, IMHO, is to attain a better pluggability which is at a higher abstraction than maintainability, extensibility , flexibility, modualrity etc.
1)actually the basic need for a design is to attain pluggability with minimum *ripple effect
*ripple effect: changes required on existing code
if the inital features are going to take care of everything an application needs, then any kind of working code will suffice. This is mostly unlikely.
Almost all the applications need to extend at some point of time and so some code needs to get pushed into the existing one. "Can the new peace of code fit in neatly without disturbing the existing code???" is the main concern.
2)the second need for a design is to achieve
Abstraction/modualrity. a good abstraction will provide a good modualrity , which helps the code getting organized into their own slots.Abstraction also helps to easily understand the given problem in the problem space as well.
maintainability is a by-product of a good abstraction.
To summarize, the need for design is due to

1.Abstracting[b] the systems to achieve maintainability and modularity and the abstraction should be fine-tuned towards a future [b]2.pluggability .

please note as change is unavoidable pluggable abstration seems to be achieved thr' good design.
An abstraction without pluggability is too short-shighted. A pluggable feature can't be attained wihoout good abstraction. So if the goal is towards obtaining a "pluggable abstraction" everything falls into place.

please comment!
[ April 28, 2003: Message edited by: aadhi agathi ]

[aadhi agathi]

Originally posted by Chris Mathews:
I guess I would add one more: risk management. We design because not to design will introduce a higher degree of risk to our projects.

could the Risk Management be called as the plugabblity plus extensibility. Because Risk Management, Feasibility study etc are more towards handling a project and towards a design.
Means that the Risk Management factor is at all levels of the project and not only towards design.

In other words, we design because we are afraid to not design

could you please eloborate on this, sounds more philosphical to me

need to choose class names, method names, etc... these decisions are what designing is all about.

i respectfuly disagree. just choosing a name/ renaming is not design , IMHO. Abstracting the problem space is the design.
but if you mean this about refactoring, Yes, i more than agree.

[Frank Carver]

To me, one of the most important things which chracterises "design" is the act of choosing. Choosing one way of doing something in preference to another; choosing whether to do something or not; choosing which thing to do first; and so on.
"Analysis" doesn't seem to have this aspect of choice. Analysis is all about building an understanding, to base the "design" choices upon.
Looked at from this point of view, choosing a name for a class or for a variable is wholly in the area of "design".

[Don Kiddick]

Why do we design ?
extendable & maintainable already mentioned.
How about supportable ? Similar but different to maintainable (in my mind). Covers things such as :
how easily can you tell if something has gone wrong (can it be monitored automatically) ?
what happens if it goes wrong ?
how easy is to recover to if things go wrong (can it recover automatically ?)

How about testable ? How easy is it to test your design ? Maybe this is not a first order aim of a design but it is certainly a second order aim as it facilitates you reaching the other aims of designs.

How about performance & scalability. You need to ensure your design scales and has "reasonable" time & space complexity.
I'm sure there's more....
D.

[aadhi agathi]

Originally posted by Frank Carver:
To me, one of the most important things which chracterises "design" is the act of choosing. Choosing one way of doing something in preference to another; choosing whether to do something or not; choosing which thing to do first; and so on.

does you use Choosing in synonymous with Abstraction. or in terms of the iterative development. How you please eloborate on how Choosing fits into design. i guess it is something to do with the domain/conceptual classes etc.

Looked at from this point of view, choosing a name for a class or for a variable is wholly in the area of "design".

is not the Abstraction more important than giving a name or making a variable. i mean can i say the process of giving names and defining variables part of abstraction

[aadhi agathi]

Originally posted by Don Kiddick:
Why do we design ?
extendable & maintainable already mentioned.
How about supportable ? how easy is to recover to if things go wrong (can it recover automatically ?)How about testable ?
How about performance & scalability.
D.

IMHO , these are only the add-ons and anything towards achieving this is called design.it is more towards an architecture and architectural design is out of scope to this topic.

please correct me in case i am not getting this one

[Don Kiddick]

Originally posted by aadhi agathi:

please correct me in case i am not getting this one

Not sure what you are saying mate. I am trying to answer Ilja's question "why do we design ?". Already covered is, "We design so we can build the system in such a way that the end result is maintainable and extendable". I was also proposing, "We design so we can build the system in such a way that it is supportable, testable and will scale well/meet our performance requirements".
D.

[aadhi agathi]

Originally posted by Don Kiddick:
Not sure what you are saying mate. I was also proposing, "We design so we can build the system in such a way that it is supportable, testable and will scale well/meet our performance requirements".
D.

let me be clear this time. the features like scalable, supportable etc are focusing towards an architetcural design and not towards an OO design. For example, consider i have a banking system and it is tested OK. we doesnt want the inital system to have all the add-on features like scalable, supportable(fail over), distitbuted etc . I use add-on as a way of features that can be added later on to the application(say using an Application server). i also cant agree Testable as a benefit of design . Rather A good design will have a supplementary test design. does this makes sense???

[Don Kiddick]

Originally posted by aadhi agathi:

let me be clear this time. the features like scalable, supportable etc are focusing towards an architetcural design and not towards an OO design.

Agreed for supportable. In the main this is an architectural design issue, although you could design in to the object model, self diagnosis, self repair and stuff like that, I think this is not that likely.
Performance I think is an OO design issue. Just using an app server doesn't give you scalability. If you make a poor choice of datastructure that means that to implement a use case requires the use of a high order algorithm (e.g O(n*n)), then your application will not be scalable.
Testable. I disagree, I think one of the benefits of doing a design is that it allows you to make the system easy to test. For example, in my designs I try to avoid the use of singletons because I know they can make my code difficult to test.
D.

[Don Kiddick]

More design goals :
Simple/Easy to understand.
Flexible (~extendable).
Robust (?)

Just throwing out ideas here

[Don Kiddick]

Low degree of coupling, high degree of cohesion.

[aadhi agathi]

Pluggable, Customizable

[aadhi agathi]

Originally posted by Don Kiddick:
Performance I think is an OO design issue.
D.

i strongly disagree. anything out of the requirement is waste of resources(KISS).

Just using an app server doesn't give you scalability. If you make a poor choice of datastructure that means that to implement a use case requires the use of a high order algorithm (e.g O(n*n)), then your application will not be scalable.

the implementation can always be changed and it will be the norm and not an exception. Separating the services(interface) with implementation does exactly that.

Testable. I disagree, I think one of the benefits of doing a design is that it allows you to make the system easy to test.

It makes easy to find the test-cases . agreed.

For example, in my designs I try to avoid the use of singletons because I know they can make my code difficult to test.

very difficult to appreciate. "Difficult to test" should not be an indication to "Change the good design principles "

[Don Kiddick]

Originally posted by aadhi agathi:

i strongly disagree. anything out of the requirement is waste of resources(KISS).

There are always implicit performance requirements for any system and sometimes explicit ones. IMHO you need to address these in design.

[aadhi agathi]

Originally posted by Don Kiddick:

There are always implicit performance requirements for any system and sometimes explicit ones. IMHO you need to address these in design.

shall we agree that Performance would be an exceptional case for less than 5% of the applications. I am looking at the topic as "Why do we desingn generally " .
Reason being it is not feasible to cover all the earthly benefits of a design.
example: we can say design helps applications to migrate between different languages. but in general that is not the benefit of a design.
I would like to hear about the approach of
1)Analysis -> Code ->(evolve) Design from the
traditional
2) Analysis -> Design ->Code
does the second approach eleminates design.
Comments are welcome as always!!

[Gopi Balaji]

Some random thoughts -
1. There are two kinds of business logic [Martin Fowler, P of EAA] - pure domain logic, and application logic.
2. OOAD can be applied very sucessfully to both, but needs different lines of approach.
3. Pure domain logic models the real world (as the text books told us). Examples - Library, BookLocation, Book, Author, Title.
4. Application logic, for the most part, does not have couterparts in the real world. Examples - Login, Session, Connection Pool, Log.
5. Designing software systems is still an art, atleast in part, if not wholly.
6. One gets to a good design by being aware of, and using where appropriate, several guidelines collected over the years (a.k.a patterns)
7. It is important to distinguish application logic vs. pure domain logic. As a by-law, there should be a clevage between them.
8. Pure domain logic has to be very extensible, flexible, pluggable (and all the other -ble s).
9. Application logic can be flexible, customizable (other -ble s) to the extent time and cost allows.
10. There is no one right design for any problem. But, there always is a better design for any given solution design to a problem.
-GB.

[Chris Mathews]

Originally posted by aadhi agathi:
i respectfuly disagree. just choosing a name/ renaming is not design , IMHO.

I have to strongly disagree with you on this.
Choosing proper names are some of the most important decisions in any design. You could have an otherwise good design but pick horrible names and very few people will be able to understand it.
The design should communicate clearly what it does, this is achieved in large part by choosing correct and appropriate names. Therefore, it goes to reason that choosing names/renaming is an important part of the design process.

[Frank Carver]

does you use Choosing in synonymous with Abstraction. or in terms of the iterative development. How you please eloborate on how Choosing fits into design. i guess it is something to do with the domain/conceptual classes etc.
I use "choosing" in its simplest, most general form; just as it is used in regular English. Any decision you make is a choice. Consider choosing whether to use the Command pattern; choosing what to name a variable; choosing whether "administrator" is a separate abstraction from "user", whether the '{' starts a new line or follows the 'if', whether to write your own routine or use one from a library, and so on.
Producing software is a series of choices, some big, some small. All of these choices are design decisions, they all affect the final form of the software.
As to why we design. We design because without design there would be no software. Deciding what to write is what programming is. It's everything that happens between understanding a need, and banging fingers on a keyboard. As software developers, design is what we do!

[Stan James]

I think one basic belief we mostly share is that careful design will give you more "goodness" in the end product. (This does not imply Big Design Up Front. Maybe you can do careful design as you code. Maybe not.)
There have been numerous contributions in this thread to defining "goodness": low coupling, high cohesion, high performance, scalability, extensibility, maintainability, robustness, etc.
I keep a list of a hundred or so such qualities around, and encourage teams to prioritize them at the start of a project so everybody knows just what we want, and what may be sacrificed to get it. Every design decision balances or compromises some of these qualities. It's helpful to think about what is promoted and what is harmed by each decision.
What qualities are most important to you? What do you do in the "design" activity to assure they show up in the end product?

[Ilja Preuss]

Wow, I didn't expect such a lively discussion when I started this thread. There are already some very interesting and inspiring thoughts here!
Regarding the notion that "without design, there would be no software" - there is certainly *some* truth in this, but I don't think it is the whole truth. It seems to me that we should care for more than being able to compile the source code when thinking about the design...
Let me summarize the needs for a "good" design from my point of view:
A good design will help us to
* test the software. I think this is a very important point - software developed without testing in mind tends to be very hard to test. And without extensive testing, we can't be sure that the software really is doing what we want it to do.
* change/extend/maintain the software. We probably all know that software always needs to be changed... :roll: To be easy to change, it needs to be
- easy to understand. How can you change something you don't understand? That is why I think that giving good names is a very important part of design.
- easy to modify. If I want to change something, I want to change as few of the existing code as possible. The design should also make it easy to "do the right things".
- robust/hard to break. If I change a part of the system, the other parts should be unaffected.
- easy to reuse. If I need part of a functionality that is already implemented in the system at another place, I should simply be able to.
Regarding performance: I think the first step is mainly to make the system easy to performance-test and easy to change. Only if you have done the former, you can use the latter to improve the performance in an informed way. Taking more than the most basic performance consideration into the early design is a very slippery slope, in my opinion.
Gopi - I don't see yet how the domain logic / application logic distinction fits into the picture. Fully agree with your other points, though.
Low coupling / high cohesion - I think these are already top-level means to get to the goals mentioned above. A design with low coupling tends to be easier to test, for example. What else comes to mind?

[Gopi Balaji]

Originally posted by Ilja Preuss:
[.. snipped ..]
Gopi - I don't see yet how the domain logic / application logic distinction fits into the picture. Fully agree with your other points, though.
[ .. snipped ..]

The distinction is important to realize because of these -
1. They need different treatments in analysis and design.
2. There should be no compromise in the design/architecture of domain logic, whereas one can live with compromises in application logic
The idea of having "testability of software system" as a design objective is interesting. Is it possible to quantify it? If so, how would you?
-GB.

[Frank Carver]

Aadhi: The most important need for design, IMHO, is to attain a better pluggability which is at a higher abstraction than maintainability, extensibility , flexibility, modualrity etc.
Ilja: Regarding the notion that "without design, there would be no software" - there is certainly *some* truth in this, but I don't think it is the whole truth. It seems to me that we should care for more than being able to compile the source code when thinking about the design...
Frank: Design ... is everything that happens between understanding a need, and banging fingers on a keyboard.
Stan: What qualities are most important to you? What do you do in the "design" activity to assure they show up in the end product?
It seems that underlying these different opinions is a whole range of different assumptions of what the word "design" (and, in particular, "OO design") actually means.
For me, every decision you make which contributes to the final solution is design. Others seem to be reserving the term for what I might label as "good design" or "effective design". Likewise, some seem to see a strong distinction between "OO" design and "architectural" design. To me that distinction doesn't seem very useful - a design decision is a design decision whether it is how many buildings to fit on Manhattan Island, or what color to paint the Brooklyn Bridge.
I can't help feeling that if the term "design" is reserved only for good/effective designs, then it does not make much sense to talk about designs which are somehow bad or less effective . But I'm sure we have all encountered such "designs"
Just as I see the definiftion of the word design as being ultimately very simple. I also see the definition of "good" design also being simple. A good design is simply one that meets all its needs.
The trick is that often not all the needs are immediately obvious. Needs such as scalability, performance, maintainability, usability, ease of deployment, development cost, stability of tools, staff skills and so on are often left unmentioned and unprioritized in the rush to list features and use cases. Finding out this sort of thing is part of the analysis activity, though.
By the way. I agree with Ilja, this is turning out to be a fascinating thread.

[aadhi agathi]

Originally posted by Frank Carver:

Likewise, some seem to see a strong distinction between "OO" design and "architectural" design. To me that distinction doesn't seem very useful - a design decision is a design decision whether it is how many buildings to fit on Manhattan Island, or what color to paint the Brooklyn Bridge.

Definitely there is a difference. An architectural design will be a very generic form
whereas a general OO design need not be more generic but flexible. For example, it is near to impossible to make a design that servces a generic concept like transaction. Ex: Banking transaction, Finance transaction and so on. But an architecture should provide the generic services like transaction, scalable etc. Don't you agree.

Martin Fowler says it here:quote Fowler
"Although it's slightly tangential to this theme, this is a good moment to throw in some advice about that most-touted benefit of object-oriented platforms: reuse. Over the years I've run into plenty of people who've talked about building a foundation of reusable frameworks on which they intend to build the next generation of applications. I've run into hardly any successes. That's even not taking into account the problems when technology platforms disappear. The problem is that it's very hard to build frameworks from scratch."

The trick is that often not all the needs are immediately obvious. Needs such as scalability, performance, maintainability, usability, ease of deployment, development cost, stability of tools, staff skills and so on are often left unmentioned and unprioritized in the rush to list features and use cases.

"starting everything from scratch" may not be applicable to OO systems,. Afterall APIs /architectures are there to get resused over and over again. If i can add-on a feature, say scalability, plugging my system in a architecture which provides scalability will do the trick. Thinking of this, avoiding things which like scalability,transaction will also be a ood design.

By the way. I agree with Ilja, this is turning out to be a fascinating thread.

count on me too
[ April 29, 2003: Message edited by: aadhi agathi ]

[aadhi agathi]

some more thoughts:-
1)design helps to get an overall view of the application, rollup or rolldown. Means it helps to restrict the area which needs attention. (just like an X-Ray). [thus a good design will also need to have a good design articraft]
2)considering design articraft as part of design. it helps to communicate
3)Helps to remove (example: redundant code] or add functionalities without hurting any other [decoupling]
4)Helps to find the components which can be reused
under different a application (high cohesion)
5)Helps to view the Problem in terms of the problem space instead of the solution space (please refer Bruce eckel's Thinking in Java 1st chapter)
6) Helps iterative development.
Take one business need -> fullfil need->
add new feature -> ensure nothing is broken
-> continue
this mode of development helps to create more flexible systems.accomadates changes with grace
7)Helps to make logical partition/layers for a single business requirement. (not always). This will help to distribute task scheduling in any project.
8) Helps to estimate the project schedule

9) Helps to estimate a new add-on requirement
10)helps to find/define system boundaries so that assembling a complex system becomes easy
please comment
Atlast , i have reached the magical 10

[aadhi agathi]

A very interesting principle referred by GodBe Explicit
[ April 29, 2003: Message edited by: aadhi agathi ]

[Ilja Preuss]

Originally posted by Gopi Balaji:
The distinction is important to realize because of these -
1. They need different treatments in analysis and design.
2. There should be no compromise in the design/architecture of domain logic, whereas one can live with compromises in application logic

I don't get it... Can you give a simple example, please?

The idea of having "testability of software system" as a design objective is interesting. Is it possible to quantify it? If so, how would you?

Well, mainly by trying to write a test and seeing how hard it is... I would say that it's mainly a function of decoupling. It is simply impractical to test every detail through the whole system, so you need to test things in isolation. For testing something in isolation, it needs to be reasonably decoupled from its surroundings.
That's one of the nice things of Test Driven Development (that is, writing the tests first) - not only do you get a testable system by definition, it will also help (or even force) you to produce a well decoupled design!

[Ilja Preuss]

Originally posted by aadhi agathi:
8) Helps to estimate the project schedule

9) Helps to estimate a new add-on requirement

I think these are interesting new items brought into the discussion!
How can a design help in estimating?
I think mainly by making it clear which parts of a system need to be touched to implement a new requirement. In fact, in my experience the reverse is certainly true - with a badly designed system, most often the only thing you can tell is that a change will likely be harder than you initially thought... :roll:
Other thoughts?
[ April 29, 2003: Message edited by: Ilja Preuss ]

[Ilja Preuss]

Originally posted by Frank Carver:
I can't help feeling that if the term "design" is reserved only for good/effective designs, then it does not make much sense to talk about designs which are somehow bad or less effective . But I'm sure we have all encountered such "designs"

Frank, it might not be obvious from the previous posts, but we are actually on the same page here!
I totally agree that to program, you can't help but design, because you need to make decisions - and the outcome certainly might be a bad design.
And you seem to agree that "getting running software" is not the only motivation for designing - otherwise every running software would be "well designed", so it seems to me...

Just as I see the definiftion of the word design as being ultimately very simple. I also see the definition of "good" design also being simple. A good design is simply one that meets all its needs.

Yes, simple - and near to useless, isn't it?
Fortunately, this thread seems to be rather succesfull in identifying the most common needs forcing our designs.
Now all we need to do is identify how to serve that needs...