Prev: UML free tools
Next: just say NO to inline SQL
From: Nick Malik [Microsoft] on 17 Feb 2007 14:09
expanding the post a bit.

"Nick Malik [Microsoft]" <nickmalik(a)hotmail.nospam.com> wrote in message
news:1vidnUC-l_0PR0vYnZ2dnUVZ_hisnZ2d(a)comcast.com...
> Hi folks,
>
> The way I see it, Patterns have two very useful purposes: to educate and
> to communication.
>
> Educate: by learning a pattern, and learning it well, the concepts that
> led to the creation of the pattern are demonstrated to me, and become
> reinforced in my thinking. I can see not only a good way to do something,
> but I can call upon a useful tool for solving a similar problem or a
> problem that appears driven by the same forces that the pattern was
> designed to address. The educational value of the pattern is inward
> focused. By learning the pattern, I improve myself.
>
> Communicate: By learning a pattern, I add to my vocabulary. I am now able
> to use the pattern name as a term, a short-hand for the specific solution
> described, and somewhat for the particular forces that led to the pattern.
> Now, when I am communicating with another developer or designer, I can use
> the term and share the idea in context, potentially helping me to
> communicate both the base idea, and perhaps to help the listener to
> understand how I want to solve a problem we are both facing. The
> communication value of the pattern is outward focused. By learning the
> pattern, I improve my communication with others.
>
> A great deal of energy and effort has been directed at mining patterns in
> our code. From patterns of low level design (like GoF) to system level
> patterns, up to ecosystem level patterns, the list of terms has grown to
> the point where it is nearly impossible to achieve the communication value
> of a pattern vocabulary without specific efforts to train all developers
> *in a setting* on a group of patterns. In other words, to create a local
> language. Useful locally... but the objective of using patterns to
> communicate remains elusive.
>
> I suggest that we should create a list of 100 patterns that everyone
> should learn, not just for the inward purpose of improving my own code
> (although that is beneficial), but mostly for the outward purpose of
> creating stronger, more specific, and higher quality communication.
>
> There are side benefits, of course. If I learn a pattern, I can reap the
> educational benefit, even if the pattern isn't completely applicable to
> the systems I write or work with. A pattern of real-time systems may not
> be useful, on the surface, for an application developer. On the other
> hand, it may open up a new horizon for me, or simply allow a real-time
> developer that additional bit of context that he or she needs in order for
> that person to communicate a novel and useful idea to me. In other words,
> my code can improve because of better communication, not because I needed
> to use the pattern per se.
>
> Why 100 patterns you ask? a) it is a rational number. Too few patterns
> and there wouldn't be sufficient breadth to say that I can compose most
> good ideas out of the basic set. Too many patterns and you don't get the
> benefit of a commonly known language. Perhaps, over time and maturity,
> our profession can grow to a basic set of 1000 terms, but for now, I
> believe that 100 is about as much as anyone can handle.
>
> I believe that we should try to create the set. Convincing folks to learn
> them is the next step, but for the sake of this discussion, I'd like to
> leave the marketing of the idea out of scope. Let's talk about what this
> set can accomplish and what it's contents should be, before we discuss how
> to convince others to learn it.
>
> So, the question I want to ask this group is two=fold.
> 1) What are the criteria for considering a pattern as part of the set of
> "the most important patterns of all time," and
> 2) What patterns do you believe should be considered to be one of this
> set.
>
> Remember, for the sake of this set, we want patterns that explain or
> demonstrate fundamental ideas, or which other patterns are composed of, so
> that we can communicate amonst ourselves. Therefore, we may elect to
> include a pattern in the set that we don't expect to use very often,
> simply because it does a fine job of explaining a key concept or being
> useful for understanding other patterns.
>
> Of course, your opinions on the value of doing this work is helpful, but
> if you'd like to offer a reason not to do this, please also offer up a
> pattern that you consider vital for this list. Criticism without
> contribution is not helpful, and I encourage others not to respond to
> folks who take that route.
>
> Some ground rules:
> 1. no patterns that describe the behavior of humans reacting to one
> another, collecting requirements, or performing the act of writing,
> deploying or maintaining software. These patterns belong to the areas
> of organizational psychology and process management. For the sake of this
> list: the pattern must be implementable in code.
>
> 2. no algorithms, even if the algorithm has been documented as a 'pattern'
> in a peer-reviewed work, this list needs to differentiate between patterns
> that establish, demonstrate, or communicate fundamental principles, not
> ones that implement specific algorithms.
>
> 3. no business rules or best practices, even if the business rule has been
> documented as a 'pattern' in a peer-reviewed work. A pattern that simply
> describes a 'common business rule' that applications in a particular space
> should implement is not useful for creating a basis of communication
> across domains.
>
> I'm thinking the set could break down this way:
> 25 low level design patterns
> 15 mid-level application architecture patterns
> 20 high-level system integration patterns
> 10 patterns related to performance and real-time systems
> 10 patterns related to data management, persistence, and retrieval
> 10 patterns related to system components that behave in a particular
> manner
> 10 misc patterns useful for describing key concepts
>
> Of course, this breakdown is part of the discussion as well. If you'd like
> to see a different breakdown of patterns, suggest one.
>
> --
> --- Nick Malik [Microsoft]
> MCSD, CFPS, Certified Scrummaster
> http://blogs.msdn.com/nickmalik
>
> Disclaimer: Opinions expressed in this forum are my own, and not
> representative of my employer.
> I do not answer questions on behalf of my employer. I'm just a
> programmer helping programmers.
> --
>
>


From: mickey on 19 Feb 2007 14:37
On Feb 18, 12:09 am, "Nick Malik [Microsoft]"
<nickma...(a)hotmail.nospam.com> wrote:
> expanding the post a bit.
>
> "Nick Malik [Microsoft]" <nickma...(a)hotmail.nospam.com> wrote in messagenews:1vidnUC-l_0PR0vYnZ2dnUVZ_hisnZ2d(a)comcast.com...
>
>
>
> > Hi folks,
>
> > The way I see it, Patterns have two very useful purposes: to educate and
> > to communication.
>
> > Educate: by learning a pattern, and learning it well, the concepts that
> > led to the creation of the pattern are demonstrated to me, and become
> > reinforced in my thinking. I can see not only a good way to do something,
> > but I can call upon a useful tool for solving a similar problem or a
> > problem that appears driven by the same forces that the pattern was
> > designed to address. The educational value of the pattern is inward
> > focused. By learning the pattern, I improve myself.
>
> > Communicate: By learning a pattern, I add to my vocabulary. I am now able
> > to use the pattern name as a term, a short-hand for the specific solution
> > described, and somewhat for the particular forces that led to the pattern.
> > Now, when I am communicating with another developer or designer, I can use
> > the term and share the idea in context, potentially helping me to
> > communicate both the base idea, and perhaps to help the listener to
> > understand how I want to solve a problem we are both facing. The
> > communication value of the pattern is outward focused. By learning the
> > pattern, I improve my communication with others.
>
> > A great deal of energy and effort has been directed at mining patterns in
> > our code. From patterns of low level design (like GoF) to system level
> > patterns, up to ecosystem level patterns, the list of terms has grown to
> > the point where it is nearly impossible to achieve the communication value
> > of a pattern vocabulary without specific efforts to train all developers
> > *in a setting* on a group of patterns. In other words, to create a local
> > language. Useful locally... but the objective of using patterns to
> > communicate remains elusive.
>
> > I suggest that we should create a list of 100 patterns that everyone
> > should learn, not just for the inward purpose of improving my own code
> > (although that is beneficial), but mostly for the outward purpose of
> > creating stronger, more specific, and higher quality communication.
>
> > There are side benefits, of course. If I learn a pattern, I can reap the
> > educational benefit, even if the pattern isn't completely applicable to
> > the systems I write or work with. A pattern of real-time systems may not
> > be useful, on the surface, for an application developer. On the other
> > hand, it may open up a new horizon for me, or simply allow a real-time
> > developer that additional bit of context that he or she needs in order for
> > that person to communicate a novel and useful idea to me. In other words,
> > my code can improve because of better communication, not because I needed
> > to use the pattern per se.
>
> > Why 100 patterns you ask? a) it is a rational number. Too few patterns
> > and there wouldn't be sufficient breadth to say that I can compose most
> > good ideas out of the basic set. Too many patterns and you don't get the
> > benefit of a commonly known language. Perhaps, over time and maturity,
> > our profession can grow to a basic set of 1000 terms, but for now, I
> > believe that 100 is about as much as anyone can handle.
>
> > I believe that we should try to create the set. Convincing folks to learn
> > them is the next step, but for the sake of this discussion, I'd like to
> > leave the marketing of the idea out of scope. Let's talk about what this
> > set can accomplish and what it's contents should be, before we discuss how
> > to convince others to learn it.
>
> > So, the question I want to ask this group is two=fold.
> > 1) What are the criteria for considering a pattern as part of the set of
> > "the most important patterns of all time," and
> > 2) What patterns do you believe should be considered to be one of this
> > set.
>
> > Remember, for the sake of this set, we want patterns that explain or
> > demonstrate fundamental ideas, or which other patterns are composed of, so
> > that we can communicate amonst ourselves. Therefore, we may elect to
> > include a pattern in the set that we don't expect to use very often,
> > simply because it does a fine job of explaining a key concept or being
> > useful for understanding other patterns.
>
> > Of course, your opinions on the value of doing this work is helpful, but
> > if you'd like to offer a reason not to do this, please also offer up a
> > pattern that you consider vital for this list. Criticism without
> > contribution is not helpful, and I encourage others not to respond to
> > folks who take that route.
>
> > Some ground rules:
> > 1. no patterns that describe the behavior of humans reacting to one
> > another, collecting requirements, or performing the act of writing,
> > deploying or maintaining software. These patterns belong to the areas
> > of organizational psychology and process management. For the sake of this
> > list: the pattern must be implementable in code.
>
> > 2. no algorithms, even if the algorithm has been documented as a 'pattern'
> > in a peer-reviewed work, this list needs to differentiate between patterns
> > that establish, demonstrate, or communicate fundamental principles, not
> > ones that implement specific algorithms.
>
> > 3. no business rules or best practices, even if the business rule has been
> > documented as a 'pattern' in a peer-reviewed work. A pattern that simply
> > describes a 'common business rule' that applications in a particular space
> > should implement is not useful for creating a basis of communication
> > across domains.
>
> > I'm thinking the set could break down this way:
> > 25 low level design patterns
> > 15 mid-level application architecture patterns
> > 20 high-level system integration patterns
> > 10 patterns related to performance and real-time systems
> > 10 patterns related to data management, persistence, and retrieval
> > 10 patterns related to system components that behave in a particular
> > manner
> > 10 misc patterns useful for describing key concepts
>
> > Of course, this breakdown is part of the discussion as well. If you'd like
> > to see a different breakdown of patterns, suggest one.
>
> > --
> > --- Nick Malik [Microsoft]
> > MCSD, CFPS, Certified Scrummaster
> > http://blogs.msdn.com/nickmalik
>
> > Disclaimer: Opinions expressed in this forum are my own, and not
> > representative of my employer.
> > I do not answer questions on behalf of my employer. I'm just a
> > programmer helping programmers.
> > --- Hide quoted text -
>
> - Show quoted text -

hii.. this is mickey thukral ..first of all Mr. MAlik i want to know
your filed ..r u in .NET or some other field
actually im a Java programmer ....
this weekend my collegues discussing bout Oracle database
is there more consideration towards DBA's in Oracle than other fields

actually thewre is not any authentic books to follow at advance
level...dats why its difficult for growing programmers in java to
choose it a long time profession ......
what you say ?

mailto : thukral_mickey(a)yahooo.com

From: Nick Malik [Microsoft] on 23 Feb 2007 09:50
"mickey" <rbarua(a)bulkpetro.com> wrote in message
news:1171913865.728905.150490(a)k78g2000cwa.googlegroups.com...
>
> hii.. this is mickey thukral ..first of all Mr. MAlik i want to know
> your filed ..r u in .NET or some other field

Hello Mickey Thukral,

I am in IT Enterprise Architecture. I am a member of a group of people who
write software that is NOT sold to the public. Our software is used to
operate the multinational corporation called Microsoft that makes,
distributes, and supports thousands of software titles every year. I'm
responsible for mundane things like systems that help collect and manage
billions of dollars in annual revenue. My responsibilities surround
governance of the IT application and project portfolio, solution quality,
application and communication standards, and technology selection. I've
spent 25 years writing code in various capacities, including pure research,
shrink-wrap, embedded firmware, and Information Technology.

> actually im a Java programmer ....
> this weekend my collegues discussing bout Oracle database
> is there more consideration towards DBA's in Oracle than other fields
>

I have no idea. There are experts in the field of "what's hot." That isn't
me. The decision of what technology to bet on is always tough. Know this:
it's a short term decision. I've changed my mind many times.

> actually thewre is not any authentic books to follow at advance
> level...dats why its difficult for growing programmers in java to
> choose it a long time profession ......
> what you say ?

Regardless of what technology or language you pick, a book won't get you to
the 'expert' level. Books may help you make the transition from novice to
practitioner, but it is up to you to get from practitioner to contributor,
and from there, to expert/source. Nothing I say or do here will change
that, even this current effort to define 100 patterns. Your experience is
not unique to Java.

Good luck in your endeavors. Java or .Net or Oracle or SQL Server (or any
of a thousand other choices)... I encourage you to pick a passion, dive in,
work to become the best you can be. Then come up for air, and see what's
next. It is less important "what you pick" than that you pick it, dive
deep, and become the best you can.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--


 | 
Pages: 1
Prev: UML free tools
Next: just say NO to inline SQL