Scott Ambler and his strawman
Ravi
argument and then knocking it down. No project ever goes through the
phases that he mentions. Disparaging something that doesn't happen
makes no sense at all.
As a person with extensive knowledge of both relational modelling and
OO technologies, I can say that whenever Scott says something about the
relational model, he is almost invariably wrong; he merely manages to
air his ignorance of the relational model to the world. In fact, one
way I use his database related articles is simple: I make sure that
none of his recommendations are implemented! That way, I know that I
have removed the really bad ideas from my designs.
Scott Ambler is a prime example of an ignoramus masquerading as a guru.
Stay away from his advice on relational theory and databases.
Scott W. Ambler
>Scott Ambler's article is a wonderful example of setting up a strawman
>argument and then knocking it down. No project ever goes through the
>phases that he mentions. Disparaging something that doesn't happen
>makes no sense at all.
Ravi, assuming that you're talking about my Glacial Methodology
article in the most recent version of OV it was meant as an April
Fool's joke and wasn't meant to be taken seriously.
For anyone interested, a more thorough description can be found at
http://www.ambysoft.com/essays/glacialMethodology.html and you're
welcome to attend the upcoming seminar this Saturday in Niagara Falls
Canada (the description is presented at
http://www.waterfall2006.com/ambler2.html )
>As a person with extensive knowledge of both relational modelling and
>OO technologies, I can say that whenever Scott says something about the
>relational model, he is almost invariably wrong; he merely manages to
>air his ignorance of the relational model to the world. In fact, one
>way I use his database related articles is simple: I make sure that
>none of his recommendations are implemented! That way, I know that I
>have removed the really bad ideas from my designs.
Really? Because I've written about both normalization as well as
denormalization at www.agiledata.org as well as several times in
print (my book Agile Database Techniques,
http://www.ambysoft.com/books/agileDatabaseTechniques.html , won a
Jolt productivity award). I've also written extensively about data
modeling with the UML (interestingly, when you Google the term "data
modeling" my article is the first one to come up, so apparently
there's a lot of people out there who think that what I have to say
about databases is pretty good). As you may know, UML data modeling
is something that is currently being implemented by IBM, Oracle, and
Sybase (all three have partial offerings already, and new versions
under way). I've written about database refactoring, and several DB
vendors as well as the Eclipse team is currently looking at building
tools to support this technique. On the object to relational (O/R)
mapping side of things, I've written the most popular, and most
extensive, paper on the subject (once again, the first article to
come up if you Google "O/R mapping" ).
So, if we're to take you at your word that you stay away from
anything that I write about, apparently you don't:
1. Normalize your database.
2. Denormalize your database.
3. Model your database schema.
4. Refactor your database schema to improve the quality of your design.
5. Map objects into relational databases.
Furthermore, at http://www.agilemodeling.com/essays/umlDiagrams.htm
I've posted some of the most popular articles about the UML diagrams
(as you'd guess, just Google "UML 2 diagrams" and guess what's #1).
>Scott Ambler is a prime example of an ignoramus masquerading as a guru.
Ravi, I suspect that somebody involved in this conversation is an
ignoramus. I don't think that it's me though.
>Stay away from his advice on relational theory and databases.
Have you ever written anything on this subject? Or do you just snipe
at other people without actually contributing anything to the community?
Do you have any specific issues with what I've written that we can
discuss, or do you just rant and make general assertions that few
others seem to agree with?
- Scott
====================================================
Scott W. Ambler
Senior Consultant, Ambysoft Inc.
www.ambysoft.com/scottAmbler.html
Refactoring Databases: Evolutionary Database Design
(www.ambysoft.com/books/refactoringDatabases.html) is now available!
Ravi
quoting some absurdities that you have mouthed, especially regarding a
series of articles in SD Magazine, I think. Those who actually have
knowledge of relational database theory know you for an ignoramus. It
is not just I who have made that comment.
I've read many of your articles, especially the agile DBA ones. When
reading your articles my first thought is, "What world is he living on?
That's not how it is done."
All the time you set up strawman arguments and then "show" that your
preferred method is superior to the strawman.
By the way, I do normalize my models to at least third normal form,
often to fifth. And the performance is better than that of
de-normalized databases! It all depends on how well you understand the
problem domain, not on mechanically following rules of normalization.
>From your writings, it is clear that you can mouth the words that
definen the threee normal forms, yet you have no understanding of them.
And my OO models are simpler yet more powerful and more reusable than
similar ones developed using open source.
As for getting a Jolt award, isn't it true that books submitted for
these awards have to pay some money to be considered?
And anyway, the fact that the software community thinks that you are a
good author is the defintive indictment of your lack of abilities. I do
not have much regard for the average software developer. I believe that
the average software developer is incompetent. Hence, when somebody
barely competent says something, it is easy for these people to believe
him without questioning, especially since they themselves lack
fundamental knowledge and wouldn't know a good idea if you hit them in
the face with it. They simply wouldn't know what questions to ask and
end up swallowing your mutterings hook. line and sinker.
Evidence for the above statement about the incomeptence of the average
software developer? Very easy: EJB. Anybody with half a brain looking
at EJBs for the first time would know that they are overly complex, and
could be much, much simpler. Yet, a whole generation of Java developers
grew up believing that EJBs are a wonderful idea. Want more? People
believing in the XML panacea, developing XSD, etc. Need even more
evidence? Look no farther than Microsoft's LINQ for C# version 3.
Anybody who knows SQL will marvel at the complexity of LINQ versus the
simplicity and declarative features of SQL.
In my mind, you are an ignoramus as far as relational theory is
concerned, and will remain so until your writings show a glimmer of
understanding.
As far as general software development is concerned, I think you are a
thought follower, not a thought leader. I believe that a few years from
now when Java is no longer popular, you will be among the first to jump
on the table and shout about the merits of the "new" thing, most likely
a dynamic language. And I'm sure you'll write a book or two, may be
even winning an odd award. And you will be as critical of Java/C/C++/C#
developers as you are today of anything related to databses. That still
does not make you a smart person.
Ravi
Ravi
"However one aspect of the impedance mismatch between object technology
and relational technology is that relational technology does not
support the concept of uni-directional relationships - in relational
databases all associations are bi-directional."
This shows that you have no idea of what relational technology is
capable of. Whenever somebody talks about uni-directional and
bi-directional relationships, I realize that they are using buzzwords
to mask their ignorance of relational theory.
I am simply not going thorugh all your writigns to find out the errors.
Just realize that I am not alone, many real thought leaders share my
opinion of you.
Ravi
Scott W. Ambler
>I believe Fabian Pascal at www.dbdebunk.com has "immortalized" you by
>quoting some absurdities that you have mouthed, especially regarding a
>series of articles in SD Magazine, I think. Those who actually have
>knowledge of relational database theory know you for an ignoramus. It
>is not just I who have made that comment.
I'll have to drop by his site again. Pascal has the unfortunate
habit of quoting people out of context, not providing links to the
source, and not copying the original author when he posts his
misquote of the week.
>I've read many of your articles, especially the agile DBA ones. When
>reading your articles my first thought is, "What world is he living on?
>That's not how it is done."
Actually, many people do in fact do it that way which may be one of
the reasons why the Agile Database Techniques book, which the site
summarizes material from, won an award.
><snip>
> >From your writings, it is clear that you can mouth the words that
>definen the threee normal forms, yet you have no understanding of them.
And yet my page is the most popular one worldwide on the subject.
>As for getting a Jolt award, isn't it true that books submitted for
>these awards have to pay some money to be considered?
In recent years the publisher needs to pay a $200 entry fee. The fee
helps to focus the publishers, and software vendors for that matter,
to nominate only products which are good enough to have a
chance. All free products, such as web sites or open source
products, do not have to pay the fee.
>And anyway, the fact that the software community thinks that you are a
>good author is the defintive indictment of your lack of abilities. I do
>not have much regard for the average software developer. I believe that
>the average software developer is incompetent.
Thanks for sharing that with us. I'm sure that everyone on this list
is in the process of forming an opinion about you too.
> Hence, when somebody
>barely competent says something, it is easy for these people to believe
>him without questioning, especially since they themselves lack
>fundamental knowledge and wouldn't know a good idea if you hit them in
>the face with it. They simply wouldn't know what questions to ask and
>end up swallowing your mutterings hook. line and sinker.
Then perhaps you should invest some time in sharing your techniques
with the rest of the world, seeing as you apparently believe that
you're pretty hot? It's pretty easy to sit on the sidelines and
snipe at people, it's not so easy to actually produce something of
value and put it out there for the rest of us to see it.
>In my mind, you are an ignoramus as far as relational theory is
>concerned, and will remain so until your writings show a glimmer of
>understanding.
Oh well. The good news is that I'm not going to lose any sleep over
the fact that you don't like me.
>As far as general software development is concerned, I think you are a
>thought follower, not a thought leader. I believe that a few years from
>now when Java is no longer popular, you will be among the first to jump
>on the table and shout about the merits of the "new" thing, most likely
>a dynamic language.
Actually, I've been pretty clear for a long time that I think that
Smalltalk is a far superior language than Java, or any other
statically typed language.
> And I'm sure you'll write a book or two, may be
>even winning an odd award. And you will be as critical of Java/C/C++/C#
>developers as you are today of anything related to databses. That still
>does not make you a smart person.
Smart enough to get books published, and awarded, from the sounds of
it. Can you say the same?
You've been pretty critical of Java yourself. Does that mean that
you're not a very smart person too?
>Here's a quote that is out there at DBDebunk.com:
>
>"However one aspect of the impedance mismatch between object technology
>and relational technology is that relational technology does not
>support the concept of uni-directional relationships - in relational
>databases all associations are bi-directional."
>
>This shows that you have no idea of what relational technology is
>capable of. Whenever somebody talks about uni-directional and
>bi-directional relationships, I realize that they are using buzzwords
>to mask their ignorance of relational theory.
Actually, it shows how Pascal likes to quote things out of
context. Were you to actually read the article,
http://www.agiledata.org/essays/mappingObjects.html , from which it
is pulled you would see how I discussed the two kinds of
relationships and how they're implemented using each
technology. With RDBs relationships are implemented using foreign
keys to other entities and are "traversed" via joins. You can
effectively traverse them in either direction, regardless of which
table they're implemented in, making them bi-directional. It is
possible, however, to implement uni-directional associations using
object technology, something that you can't do using relational
technology. Hence it's a minor addition to the technical impedance mismatch.
However, seeing as you disagree with me please educate me as to how a
uni-directional relationship would actually be implemented in a
relational database which wouldn't in effect be a bi-directional
association. You claim to be an expert, so this should be a simple
thing for you to do.
>I am simply not going thorugh all your writigns to find out the errors.
>Just realize that I am not alone, many real thought leaders share my
>opinion of you.
Then I hope that they have the integrity to contact me and open up a
discussion with me. Pascal clearly doesn't. You'll probably notice
how I've copied him on this email.
Ravi
relational database, why should there be a need for uni-directional
mapping?
What does it really mean in the context of relational databases? Also,
isn't the same true of OO, too, that given a uni-directional mapping,
one can always infer the mapping in the other direction, through the
object identifier?
In OO, it is difficult to model many to many relationships because one
would need to create an extra class. For example, if a bank has the
rule that a customer can have more than one account, and an account can
belong to more than one customer/owner, then we can model it trivially
using database entities, but this necessitates the creation of
explicit bi-directional mapping in OO. One solution is to have a
variablef for Account[] (array) in Customer class, and a variable for
Customer[] array in Account class. The problems with keeping this
synchronized are well known.
The main reason that this happens is that one is violating the DRY
principle: the relationship between customers and accounts is kept in
two places. As usual, when a fundamental principle is violated, there
will be problems. There are two ways to handle this: write code to
manage the dependencies (not a very good solution); or design it in
such a way that this case never arises. Unfortunately, with a class
based approach that is difficult, but not impossible.
Such an issue does not arise at all in relational data modelling. To
claim that this is a limitation of relational databases shows that the
author is either (a) ignorant of the uses of a relational database and
its theory; or (b) is so focussed on the OO way of doing everything
that he forgets that the aim of developers should be to solve problems
using the appropriate technology, not to force everything into one
paradigm; or (c) intentionally shows faults (real or imagined) in some
paradigm just to flaunt ones expertise with the currect fad.
None of these cases shows the author in a good light. Hence my
criticism of your lack of knowledge, that being the most charitable
interpretation.
Ravi
Ravi
out.
You said, "Figure 4 hints at an important part of the technical
impedance mismatch between object technology and relational technology.
Classes implement both behavior and data whereas relational database
tables just implement data. The end result is that when you're
mapping the properties of classes into a relational database you end up
mapping operations such as getTotalTax() and position() to columns.
Although it didn't happen in this example, you often need to map two
operations that represent a single property to a column - one
operation to set the value, e.g. setFirstName(), and one operation to
retrieve the value, e.g. getFirstName(). These operations are
typically called setters and getters respectively, or sometimes
mutators and accessors." in
http://www.agiledata.org/essays/mappingObjects.html.
Now that statement is interesting, because in the physical data
modelling layer you never create computed values as database columns.
But if you were to come out and say that just like the getTotalTax()
method, one could have a stored procedure that calculates the total
tax, then the advantage of OO that you talk about is not clear. And you
could not sell your books! In fact, any decent data modeller (there
are very, very few of them around!) would never have such a computed
field in their model anyway. They know all too well the difficulty in
synchronizing the data with changes as they occur.
This shows how much experience you have with good data modellers. And
that is why anybody who knows something about data modelling and
relational databases will stay away from your work. And so, too, should
anybody trying to learn about these things.
The other thing that you allude to, getters and setters, actually
points to a much deeper problem with OO. In OO, for every variable, you
have to write explicit setters and getters to access it; or declare the
variables public which is not considered good OO since it violates
encapsulation. So, to write a report using an OO language for data
gathered from a database, one would need to have all the getters
defined. This creates a dependency since the getters may be needed only
for the report, not for the problem domain! Why should my class know
that it has to have a getter just because a report needs it?
Such a problem does not arise in databases since all the entities
columns are visible to SQL statements, the DBMS (database management
system) does the hard, mundane task of validating the column names,
etc. The declarative nature of SQL is much simpler and easier to
understand.
You need getters and setters in OO, one for each column/variable. In
relational databases, you need only four generic operations: select,
insert, update and delete to do this. These four operators are
applicable for all tables. There is no need to write explicit code for
each column for any one of these columns! And therein lies the power
and simplicity of SQL!
Not to be so harsh on OO, it has its uses. So does relational
technology. Criticism of relational technology should be based on
facts, not ignorance.
Ravi
PS: Please do not challenge my integrity or dare me in any way. I have
made some statements to the effect that I think you do not know enough
about the subject matter, and hence that people should stay away from
you. I believe that these are reasonable statements. You can always
prove me wrong and I'll admit it.
I have a policy that if one continues on these non-sequitirs, I just
walk away from the discussion.
Ravi
"You've been pretty critical of Java yourself. Does that mean that
you're not a very smart person too? "
I fail to see the logical connection between the two statements.
Does this mean that if one criticizes Java, one is dumb? If so, why?
This is the sort of logic that can pass by the average software
developer without comment, yet is so blatantly inflammatory and totally
devoid of meaning that one is simply amazed at the audacity of the
author in stating it.
Ravi
Ravi
with one of the authors stating something to the effect that one should
not design anything in 3rd Normal Form because it always results in
poor performance!
Now how much respect can I have for this author? Even though the bool
was published by Oracle Press! This statement clearly shows that the
author has never designed a real application. A design done properly in
third normal form often outperforms a denormalized design.
Authors don't impress me just because they are authors. One can be a
published author and an ignoramus, too.
The fact that you have published a book merely means that some
publishing house thought they could possibly make a profit by selling
it to a gullible public, nothing more.
Evaluating your writings on the basis of content, not reputation, I
feel that, as far as relational databases and theory are concerned, you
have much to unlearn and much to learn. I have pointed out several
points in your writings that show your lack of knowledge and
understanding.
What are you going to do about it? Are you going to take it up as a
chaleenge and learn about relational theory?
I work in Toronto, too. So, if you want, I'm willing to spend the time
to help you learn.
Ravi
markcol...@gmail.com
>Scott Ambler is a prime example of an ignoramus masquerading as a guru.
Mark Collins-Cope.
Ravi
that in the interests of fairness you will issue him a public warning,
too. I'm not holding my breath, though!
I gave my reasons for calling him an ignoramus. Disagree with me on
substance if you can.
I gave detailed reasons why he does not know what he is talking
about, hence people should not listen to him when he talks about
relational model and data modelling.
Disagree with me on the facts if you can. Do not stop me from
calling a spade a spade.
I repeat, as far as relational theory is concerned, Scott Ambler is
an ignoramus and one should stay away from him. This is a fact stated
by the highest authorities (Pascal, et al) in the relational world and
common knowledge among those who know relational theory. There is
nothing personal here.
By the way. I read your first article on OO vs Procedural. That told me
how much you understand about OO and procedural, too.
The thing is that most people haven't seen any really good
application, and wouldn't be able to understand one if they saw it.
Hence, they perpetuate mediocrity, and when mediocrity is attacked,
they close ranks and claim the attacks are personal.
Ravi
markcol...@gmail.com
No-one objects to you making technical points, however there are ways and means of doing it without causing offence.
Implying, for example, that all software developers are all stupid is hardly likely to help you win friends and influence people, is it?
You could, for example, have tried the following approach with Scott:
***
I noticed on Fabian Pascal's site that you said the following:
and relational technology is that relational technology does not
support the concept of uni-directional relationships - in relational
databases all associations are bi-directional."
***
This would have *avoided* a confrontational situation, Scott would have answered and you could have discussed your views with him - putting your position. Without the name calling. Scott is very obviously not an ignoramus (which is a very sweeping statement). Like us all, he's probably not right 100% of the time. But the purpose of discussion is enable a two way learning process to take place. But that requires that both parties show respect to each other.
Why don't you try that appoach (now - we can all forget the past and have an interesting debate) - and see where it goes. It's a better way.
Mark.
Ravi
that if I am too polite, people will take that for mild disagreement
(or even agreement) while what I want to express are my strong feelings
of disagreement.
The way you phrased it in the hypothetical criticism sounds as if it
were lack of knowledge and understanding on the part of the person
commenting that needs to be explained, not that the critic strongly
disagrees with the author.
I still haven't seen a public mail asking Scott Ambler to be polite.
Hoping to see one soon.
Ravi
Scott W. Ambler
Folks, I apologize for this entire conversation. One of the
downsides of open and honest communication is that some people abuse
the opportunity.
- Scott
At 12:33 PM 3/30/2006, Ravi wrote:
>Re the bi-directional, uni-directional thing, when modelling data in a
>relational database, why should there be a need for uni-directional
>mapping?
Perhaps because you want to model reality? Sometimes a entity knows
about another entity but not the other way around. For example,
senior management in an organization has identified someone as being
on the fast track, but that person isn't informed of this fact so as
not to negatively influence their progress. Therefore there is a
relationship from Fast Track to Employee but not in the opposite direction.
The fundamental point that I was making in the article was that these
sorts of relationships can't be implemented in RDBs but they can be
implemented using object technology. In fact, although I didn't
discuss it explicitly in that article (I have done so in The Object
Primer, www.ambysoft.com/books/theObjectPrimer.html and at IBM
DeveloperWorks) bi-directional associations in object technology are
really the combination of two uni-directional associations.
>What does it really mean in the context of relational databases? Also,
>isn't the same true of OO, too, that given a uni-directional mapping,
>one can always infer the mapping in the other direction, through the
>object identifier?
Perhaps, but it can be very difficult to traverse without some
external code to do the work.
>In OO, it is difficult to model many to many relationships because one
>would need to create an extra class.
That is one way to implement a many-to-many, but not the only
way. See
http://www-128.ibm.com/developerworks/webservices/library/ws-tip-objrel4/
for a discussion. The Object Primer 3rd Edition has a more detailed
discussion, but the fundamentals are there.
> For example, if a bank has the
>rule that a customer can have more than one account, and an account can
>belong to more than one customer/owner, then we can model it trivially
>using database entities, but this necessitates the creation of
>explicit bi-directional mapping in OO. One solution is to have a
>variablef for Account[] (array) in Customer class, and a variable for
>Customer[] array in Account class. The problems with keeping this
>synchronized are well known.
Yes, this is well known and fully automated by most OO modeling tools
that I know of let alone OO frameworks. This is pretty basic stuff.
>The main reason that this happens is that one is violating the DRY
>principle: the relationship between customers and accounts is kept in
>two places. As usual, when a fundamental principle is violated, there
>will be problems. There are two ways to handle this: write code to
>manage the dependencies (not a very good solution); or design it in
>such a way that this case never arises. Unfortunately, with a class
>based approach that is difficult, but not impossible.
>
>Such an issue does not arise at all in relational data modelling. To
>claim that this is a limitation of relational databases shows that the
>author is either (a) ignorant of the uses of a relational database and
>its theory; or (b) is so focussed on the OO way of doing everything
>that he forgets that the aim of developers should be to solve problems
>using the appropriate technology, not to force everything into one
>paradigm; or (c) intentionally shows faults (real or imagined) in some
>paradigm just to flaunt ones expertise with the currect fad.
I never claimed that this is a limitation of relational
databases. Please show otherwise by providing a reference where I
have explicitly done so, or please stop making these false
accusations and have the integrity to apologize for your previous postings.
WRT point A, I think my body of work published online which describes
how to use RDBs effectively in practice speaks for itself.
As for your point B, please refer to
http://www.agiledata.org/essays/referentialIntegrity.html#ImplementationStrategies
where I have gone out of my way to discuss the trade-offs of where to
implement shared logic (actually, if you know of a better discussion
of this sort of material that is available online I'd like to know
about it so I can link to it from this article).
Also, with respect to point C please refer to
http://www.agiledata.org/essays/drivingForces.html where I discuss
the idea that OO should drive the data stuff and vice versa.
Ravi, your false accusations are becoming tiresome.
>None of these cases shows the author in a good light. Hence my
>criticism of your lack of knowledge, that being the most charitable
>interpretation.
Ravi, instead of trying to insult me perhaps you should instead
attempt to have a conversation with me. As you can see, although
perhaps not acknowledge, your concerns don't appear to hold
water. You're wasting the time of the people on this list, and
making a fool of yourself in the process.
Perhaps if you had read the entire article, you would have found
http://www.agiledata.org/essays/mappingObjects.html#PerformanceTuning
where I do in fact discuss stored functions. Also, I discuss stored
procedures at
http://www.agiledata.org/essays/referentialIntegrity.html#BusinessLogicImplementationOptions
and in other articles on the Agile Data site.
Granted, I don't have an explicit section in the article discussing
how to map a attribute to a store function, or to a calculated column
though. Perhaps instead of trying to publicly embarrass me, don't
you think it would have been more mature to instead send me a private
email, or perhaps post a question on one of my mailing lists, to
strike up a conversation on the subject?
>This shows how much experience you have with good data modellers. And
>that is why anybody who knows something about data modelling and
>relational databases will stay away from your work. And so, too, should
>anybody trying to learn about these things.
Ravi, considering my writings seem to come up at the top of Google
searches it doesn't appear that people are staying away from my
writings due to an omission or two.
>The other thing that you allude to, getters and setters, actually
>points to a much deeper problem with OO. In OO, for every variable, you
>have to write explicit setters and getters to access it; or declare the
>variables public which is not considered good OO since it violates
>encapsulation.
Yes, there are different ways to achieve this (you could also take a
meta-object approach, but it's a bit goofy). That's an aspect of the
technology. With procedural technologies you have scoping issues
with variables, a different flavor of the same general issue. The
world isn't perfect.
>So, to write a report using an OO language for data
>gathered from a database, one would need to have all the getters
>defined. This creates a dependency since the getters may be needed only
>for the report, not for the problem domain! Why should my class know
>that it has to have a getter just because a report needs it?
Well, as I write at http://www.agiledata.org/essays/reporting.html
you might want to consider reporting from the database, not your
object application. Weren't you just ranting about using the right
technology for the job?
Also, with reflection (not supported by all OO languages) it is
possible to do reporting in a fairly straightforward manner, although
I'm not sure why you'd bother with that approach.
>Such a problem does not arise in databases since all the entities
>columns are visible to SQL statements, the DBMS (database management
>system) does the hard, mundane task of validating the column names,
>etc. The declarative nature of SQL is much simpler and easier to
>understand.
And therein lies the challenge of increased coupling, something I
discuss at
http://www.agiledata.org/essays/implementationStrategies.html and of
course compare and contrast the advantages and disadvantages of
various approaches.
> You need getters and setters in OO, one for each column/variable. In
>relational databases, you need only four generic operations: select,
>insert, update and delete to do this. These four operators are
>applicable for all tables. There is no need to write explicit code for
>each column for any one of these columns! And therein lies the power
>and simplicity of SQL!
>
> Not to be so harsh on OO, it has its uses. So does relational
>technology. Criticism of relational technology should be based on
>facts, not ignorance.
>
>Ravi
>
>PS: Please do not challenge my integrity or dare me in any way. I have
>made some statements to the effect that I think you do not know enough
>about the subject matter, and hence that people should stay away from
>you. I believe that these are reasonable statements. You can always
>prove me wrong and I'll admit it.
Ravi, if you continue to unfairly attack my work then yes, I will
continue to challenge your integrity.
And, as far as integrity goes, if you actually believe what you're
writing about then please copy your manager on your postings. I'm
sure that they'll be impressed by your vast knowledge of software
development and in your people skills.
> I have a policy that if one continues on these non-sequitirs, I just
>walk away from the discussion.
That doesn't surprise me at all.
At 02:55 PM 3/30/2006, Ravi wrote:
>Scott said,
>
>"You've been pretty critical of Java yourself. Does that mean that
>you're not a very smart person too? "
>
> I fail to see the logical connection between the two statements.
>Does this mean that if one criticizes Java, one is dumb? If so, why?
I'm just trying to understand your convoluted thought process
Ravi. You sling insults around like there's no tomorrow, then a few
paragraphs later you appear to be doing what you just insulted.
>This is the sort of logic that can pass by the average software
>developer without comment, yet is so blatantly inflammatory and totally
>devoid of meaning that one is simply amazed at the audacity of the
>author in stating it.
Have you read your postings to this list?
At 03:50 PM 3/30/2006, Ravi wrote:
>I found this text on the cover page of "The Complete Oracle Reference"
>with one of the authors stating something to the effect that one should
>not design anything in 3rd Normal Form because it always results in
>poor performance!
>
>Now how much respect can I have for this author? Even though the bool
>was published by Oracle Press! This statement clearly shows that the
>author has never designed a real application. A design done properly in
>third normal form often outperforms a denormalized design.
And yet apparently this person was able to get their work accepted by
Oracle Press, their work got through the review process, and has been
successfully published. Perhaps you shouldn't judge a book by its cover page?
>Authors don't impress me just because they are authors. One can be a
>published author and an ignoramus, too.
>
>The fact that you have published a book merely means that some
>publishing house thought they could possibly make a profit by selling
>it to a gullible public, nothing more.
Actually, I've (co)-written 19 books with at least 5 different
publishing houses (mergers within the industry make counting a
challenge). I suppose that we could assume that all of the editors,
reviewers, co-authors, and customers involved are guillible
ingnorami. Another assumption might be that you're simply a
crank. I wonder which is more likely.
>Evaluating your writings on the basis of content, not reputation, I
>feel that, as far as relational databases and theory are concerned, you
>have much to unlearn and much to learn. I have pointed out several
>points in your writings that show your lack of knowledge and
>understanding.
And yet, when I was given an opportunity to respond it appears that
your evaluation may not have been all that accurate. That's one of
the advantages of conversation that your good buddy Fabian Pascal
doesn't seem to appreciate.
>What are you going to do about it? Are you going to take it up as a
>chaleenge and learn about relational theory?
I'm constantly learning more about relational databases, and a wide
range of other topics for that matter. Grow up.
>I work in Toronto, too. So, if you want, I'm willing to spend the time
>to help you learn.
To learn what? How to make a fool out of yourself in a public
discussion forum?
At 08:21 AM 3/31/2006, Ravi wrote:
<snip>
> I repeat, as far as relational theory is concerned, Scott Ambler is
>an ignoramus and one should stay away from him. This is a fact stated
>by the highest authorities (Pascal, et al) in the relational world and
>common knowledge among those who know relational theory. There is
>nothing personal here.
Actually, what Pascal has posted is an opinion, not a
fact. Furthermore, as you know in the private emails with him that
I've copied you on, he's not exactly open to discussion. He simply
posts his biased opinions, typically without providing context, and
brooks no discussion with the people he attacks. You might want to
aspire to a higher standard than what Pascal prescribes to.
>By the way. I read your first article on OO vs Procedural. That told me
>how much you understand about OO and procedural, too.
Mark, apparently you're an ignoramus too! ;-)
However, I'm sure that if you fly to Toronto, Ravi would be willing
to educate you.
> The thing is that most people haven't seen any really good
>application, and wouldn't be able to understand one if they saw it.
>Hence, they perpetuate mediocrity, and when mediocrity is attacked,
>they close ranks and claim the attacks are personal.
- Scott
markcol...@gmail.com
The way you phrased it in the hypothetical criticism sounds as if it
were lack of knowledge and understanding on the part of the person
commenting that needs to be explained, not that the critic strongly
disagrees with the author.
I think the point here is that until you listen to what someone else has to say (not third party renditions of what they had to say once - apparently), you can't really know if you disagree or not. Very often technical disagreements are miscommunication (or differences in emphasis).
Saying "I don't understand what you mean" is not the same as saying "I don't know anything" - it just means that you don't understand what someone is saying - pure and simple. So you ask "could you explain that in more detail"
>Hoping to see one soon.
Mark.
Ravi
Is it OK for an author to insult his critics but not OK for a critic
to point out the fallacies in his argument? I am still waiting for a
public statement from you to ask Scott Ambler to be polite.
I am sure that being fair minded, you will do so.
Ravi
Ravi
my criticism of the strawman argument.
I could spend my weekend arguing and countering whatever inaccuracies
Scott throws, but it is simply a waste of time. It is much better for
the discerning readers to form their own judgments.
Ravi
markcol...@gmail.com
Scott has been pretty restrained in answering you. You opened a conversation with an insult - it was that that I was criticising.
Why don't you try your new people friendly approach with my OO vs procedural thing?
Ciao,
Mark.
+44 (0)20 8579 7900 or :+44 (0)777 163 6882
Author: "Agile Development with Iconix Process"
Editor: www.ratio.co.uk/objectiveview.html
---------------------------------------------------------------------------
recursion is - of course - a form of magic
Ravi
insulting language he uses while stating opinions.
And your first mail to me was not a lesson in politeness, either. Read
it again.
Birds of a feather flock together, I guess.
Ravi
Amy Hoy
sick of seeing such childish, unjustified spewing in my email box.
Amy
markcol...@gmail.com
Ravi
Revel in your greatness.
m...@ratio.co.uk wrote:
> I tried.
> Bye Ravi!
>
> Mark.
>
> On 31/03/06, Ravi <ravi...@gmail.com> wrote:
> >
> >
> > Wow! Scott was restrained? Please, please read his posts and the
> > insulting language he uses while stating opinions.
> >
> > And your first mail to me was not a lesson in politeness, either. Read
> > it again.
> >
> > Birds of a feather flock together, I guess.
> >
> > Ravi
> >
> >
> > >
> >
>
>
> --
> Mark Collins-Cope
> Ratio - Training, Consultancy and Development
> --------------------------------------------------------------------------
> +44 (0)20 8579 7900 or :+44 (0)777 163 6882
> Author: "Agile Development with Iconix Process"
> Editor: www.ratio.co.uk/objectiveview.html
> ---------------------------------------------------------------------------
> recursion is - of course - a form of magic
>
> ------=_Part_13324_6672992.1143819936987
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> I tried.<br>
> Bye Ravi!<br>
> <br>
> Mark.<br><br><div><span class="gmail_quote">On 31/03/06, <b class="gmail_sendername">Ravi</b> <<a href="mailto:ravi...@gmail.com">ravi...@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> <br>Wow! Scott was restrained? Please, please read his posts and the<br>insulting language he uses while stating opinions.<br><br>And your first mail to me was not a lesson in politeness, either. Read<br>it again.<br><br>
> Birds of a feather flock together, I guess.<br><br>Ravi<br><br><br><br> +44 (0)20 8579 7900 or :+44 (0)777 163 6882<br>Author: "Agile Development with Iconix Process"<br>Editor: <a href="http://www.ratio.co.uk/objectiveview.html">www.ratio.co.uk/objectiveview.html</a>
> <br>---------------------------------------------------------------------------<br>recursion is - of course - a form of magic
>
> ------=_Part_13324_6672992.1143819936987--
Ravi
Tim
Both were rude. And both need to apologize.
but banning is wrong.
Rebecca Wirfs-Brock
Every time I heard Ravi and Scott use disparaging arguments/personal
slights, I felt like I was getting punched in the stomach by a
bully.... As a reader of this discussion group I'm left with a bad
taste and I'm not likely to read emails from either of these two
people if it isn't going to be a reasoned discussion..
I didn't know what launched Ravi into such a full frontal attack (did
I miss an email?)...and to me, Scott iwas a little testy
replying. But it is hard to not slug back when someone punches you
in the gut. Scott apologized to the mailing group, but not to Ravi.
Thanks Scott. But you two guys still have an axe to grind....
There are probably interesting points of discussion that could be
discussed,..heck I might even learn something from their dialog. But
until you can have a reasoned discussion, I don't want to listen in any more
Rebecca Wirfs-Brock
Rebecca Wirfs-Brock President, Wirfs-Brock Associates
website: www.wirfs-brock.com blog:
http://www.wirfs-brock.com/rebeccasblog.html
cell: 503-313-4978 phone: 503-625-9529
reb...@wirfs-brock.com fax: 503-625-1969
"A man should learn to detect and watch that gleam of light which
flashes across his mind from within, more than the lustre of the
firmament of bards and sages. Yet he dismisses without notice his
thought, because it is his." --Ralph Waldo Emerson
Don't you want to take responsibility for your design?
Tim
He later gave enough reasons to make one think about Scott's
competence.
To me, it looks like Scott was upset that somebody even dared to
question him. And he fought viciously claiming that because he was an
author he was always correct.
Ravi should moderate his tone. A lot. :-)
Tim
like it when a contributor is questioned! Cute! Very cute!
So what does this group consist of? Contributors to this magazine, and
a few who may have strolled in as a result of the article on Mr. F
Pascal's site. The latter group is not likely to be kind to Scott
Ambler at all because his abilities (or lack thereof) are well known.
Scott W. Ambler
At 12:33 PM 3/31/2006, Rebecca wrote:
>I've been watching and reading these emails for a day now. Ouch!
>Every time I heard Ravi and Scott use disparaging arguments/personal
>slights, I felt like I was getting punched in the stomach by a
>bully.... As a reader of this discussion group I'm left with a bad
>taste and I'm not likely to read emails from either of these two
>people if it isn't going to be a reasoned discussion..
>
>I didn't know what launched Ravi into such a full frontal attack (did
>I miss an email?)...and to me, Scott iwas a little testy
>replying. But it is hard to not slug back when someone punches you
>in the gut. Scott apologized to the mailing group, but not to Ravi.
>Thanks Scott. But you two guys still have an axe to grind....
Rebecca, you didn't miss an email. Ravi just decided to randomly
attack me without provocation. As far as my being testy, I'm
sorry. But the fact is that as you know I have made an incredible
amount of information available, free of charge, on the
web. Furthermore, I go out of my way to be available for people to
ask me questions and to discuss what I've published, as you also know
in other lists which I put a fair bit of time into to administer. So
excuse me for getting a little miffed when I get attacked, out of the
blue, in an incredibly rude and frankly ignorant manner. And, as
Mark pointed out, I've been incredibly patient with the entire situation.
And no, I don't in any way feel that I have to apologize to Ravi.
>There are probably interesting points of discussion that could be
>discussed,..heck I might even learn something from their dialog. But
>until you can have a reasoned discussion, I don't want to listen in any more
Please go back and read his original email. Do you really think that
anyone could have a reasoned discussion after that, or after his
continued attacks?
At 01:20 PM 3/31/2006, Tim wrote:
>I saw Ravi make a claim that Scott's argument was not based on facts.
>He later gave enough reasons to make one think about Scott's
>competence.
Please go back and reread my responses. Ravi clearly misrepresented
what I had written or had missed the spots where I was actually
covering what he was complaining about.
>To me, it looks like Scott was upset that somebody even dared to
>question him. And he fought viciously claiming that because he was an
>author he was always correct.
No, I was upset because of Ravi's abusive tone and unfair
accusations. BTW, I didn't once say that I was always correct, so
please stop misrepresenting what I said.
- Scott
remco...@gmail.com
Scott W. Ambler wrote:
> Answering several emails at once.
>
> Folks, I apologize for this entire conversation. One of the
> downsides of open and honest communication is that some people abuse
> the opportunity.
>
> - Scott
>
> At 12:33 PM 3/30/2006, Ravi wrote:
>
> >Re the bi-directional, uni-directional thing, when modelling data in a
> >relational database, why should there be a need for uni-directional
> >mapping?
>
> Perhaps because you want to model reality? Sometimes a entity knows
> about another entity but not the other way around. For example,
> senior management in an organization has identified someone as being
> on the fast track, but that person isn't informed of this fact so as
> not to negatively influence their progress. Therefore there is a
> relationship from Fast Track to Employee but not in the opposite direction.
the fast track" ?
I think your bi-directional or unidirectional are not very precise in
math for example a function is not invertible because it is not 1-1. I
think that is also true for relations aka tables. for example you can
find for every house address a house number but you can not find a
address if you only know the house number and not the street and city.
so relations in the relational model can also be uni-directional if you
look at them as functions (also a kind of relation in math) .
Rebecca Wirfs-Brock
>Please go back and read his original email. Do you really think that
>anyone could have a reasoned discussion after that, or after his
>continued attacks?
Scott-
I diid that.. I know you as a balanced, thoughtful designer. And I
appreciate you putting out plenty of information for public
consumption on your web site.
No, I don't expect any reasoned discussion after all that has gone
on. I just hope others aren't gun shy about asking questions, having
collegial discussions, and learning, agreeing to disagree, etc. on
this discussion group.
And on that note, my copy of Refactoring Databases just showed up
today. I'm looking forward to reading it.
Best wishes,
Rebecca
p.s. One thing I'd like to start discussing, perhaps on this website
is some nitty gritty details about aspects...if you have used them in
novel ways (or find their use intriguing to debug or document), I'd
like to hear about it...and start a dialog. I'm still trying to wrap
my head around the significance/balance of aspects in a typical IT or
Enterprise application design
Tim
Fabian Pascal is right. You guys have no interest in learning anything.
Ambler balanced? Ha! Ha! Nice joke!
If Scott Ambler can write a book on refactoring databases, an atheist
can become the Pope! Or maybe even Osama bin Laden can become the
pope!
What a sorry state of affairs the software world is in!
Tim
Now that it seems that knowledgeable people are beginning to look in
and express their views, you'll have to start thinking a bit.
Mark, you may have booted Ravi from the group. How many others are you
going to boot?
Rebecca Wirfs-Brock
I do want to learn things. Sure, an atheist can become pope (as long
as he doesn't let on he's an atheist ;-), but if the atheist is a
female, well, that's just not possible)....but what does that have to
do with the price iof tea in China? or a good round of discussion...?
Ambler has a mission (agility) and a platform for speaking out....and
he cares about what he does. I often point my design students to
Scott's website for short descriptions of how to use UML, point them
to others' sites, too...
This, however, is a forum...so we all==me included== (and damn, I
don't want to be tagged as "just another one of those schmalzy
authors") should be using it to try to learn and grow.
BTW, one of my favorite things to do is try something new just to see
whether it "shakes" up the way I have of seeing the world. A year ago
I took a foray into rule based systems and how they could be
integrated into oo applications...that was interesting...any time
someone wants to talk about rules engines meets oo design, well, give
me a holler........ This past term I took Latin, of all things, at a
local college one night a week. There I learned that programming
languages are far easier to learn than Latin...and it has made me a
more thoughtful programmer and explainer of oo concepts to object newbies.
Tim, are you a db guy? What's your work all about? Maybe we could
have a discussion about some ideas you might want to kick around.
BTW, I do respect Scott. I don't always agree with him. Don't always
agree with Bob Martin or Eric Evans or Alan Shalloway either (these
are some folks I've had design conversations with). But I always
learn something by really reflecting on why I have a difference of
opinion (and why I think the way I do about some issue).
Take care...
Rebecca
At 03:17 PM 3/31/2006, you wrote:
>I see a nice closing of ranks among authors. Good! Good!!
>
>Fabian Pascal is right. You guys have no interest in learning anything.
>
>Ambler balanced? Ha! Ha! Nice joke!
>
>If Scott Ambler can write a book on refactoring databases, an atheist
>can become the Pope! Or maybe even Osama bin Laden can become the
>pope!
>
>What a sorry state of affairs the software world is in!
Rebecca Wirfs-Brock President, Wirfs-Brock Associates
Tim
There is a reason the database folk do not like Scott Ambler. And it
is simply this: His knowledge of data modelling is lacking in many
fundamental respects, (show any DBA his articles on Agile Data
Modelling and get their opinion), yet he writes holier than thou
articles about database professionals asking them to become agile and
join the "brave new world" of Agile, OO methodology, etc. For him to
write a book on database refactoring is risible.
No one who has even an inkling of database theory or worked with
databases for any length of time gives any credence to his views. Only
those people who grew up with C/C++/Java/C# or without any background
in relational theory will buy his database books. Any database
professional will read his books and understand that the author has
nothing worthwhile to say, in fact, that the author's lack of knowledge
of this field is amazing. See the comments at
http://www.dbdebunk.com/page/page/1514543.htm and his articles on UML
data modelling.
The first question one asks of the UML data modelling articles is,
"What does UML add to data modelling?" The clear answer is, "Nothing."
So what is the author talking about? It seems he wants to use UML as
the "tool" to do data modelling! Now, UML in this case just becomes a
tool to do data modelling, just like Oracle Designer, ERWin, etc. Has
anything new been added to the body of knowledge regarding data
modelling? No. Yet, Scott continues to flaunt his contributions to "UML
Data Modelling" as examples of his contributions to the field! If this
does not showcase his lack of knowledge, what does? Everyone knows it
is essentially trivial to learn how to use a tool to do certain things.
Somebody who writes articles on how to use Eclipse with JSP pages
usually does not claim that this makes him an expert on OO philosophy!
Likewise, writing articles on UML data modelling and Agile data
modelling (whatever that is!) does not make one an expert in relational
theory or data modelling.
Hence, when news comes out that Scott Ambler has written a book on
"Database Refactorings", the knowledgeable database professional can
only laugh and marvel at the fact that there are people willing to
invest the time to read it!
Notice, by the way that he has not answered the question of uni- and b-
directional mapping raised by remco.greve (#8 post above). He can not
provide any convincing answer to this issue.
Read his articles on agile data modelling and note the condescending
tone that he takes towards data professionals. His tone is apparent in
many of his database related articles. So, I can understand why Ravi
criticizes his articles related to databases and relational theory. I
did not see Ravi criticize any other non-database realted articles.
Notice also Scott's rude tone in the posts and his statements
constantly flaunting his "author"ity without providing any defence of
the criticisms. And essentially stating that only those who have
published books can argue with him. His constant references to himself
as an author; and, in a crowing tone, asking Ravi to point out his
writings before he can discuss anything with him are examplars of
Scott's style.
Tim
Scott W. Ambler
> > >Re the bi-directional, uni-directional thing, when modelling data in a
> > >relational database, why should there be a need for uni-directional
> > >mapping?
> >
> > Perhaps because you want to model reality? Sometimes a entity knows
> > about another entity but not the other way around. For example,
> > senior management in an organization has identified someone as being
> > on the fast track, but that person isn't informed of this fact so as
> > not to negatively influence their progress. Therefore there is a
> > relationship from Fast Track to Employee but not in the opposite direction.
>Is that not because proposition/relation is "knowing" and not "is on
>the fast track" ?
>I think your bi-directional or unidirectional are not very precise in
>math for example a function is not invertible because it is not 1-1. I
>think that is also true for relations aka tables. for example you can
>find for every house address a house number but you can not find a
>address if you only know the house number and not the street and city.
>so relations in the relational model can also be uni-directional if you
>look at them as functions (also a kind of relation in math) .
That might be true in theory, but my focus is on actual practice. In
practice, there is no native way to actually implement
uni-directional relationships in the major RDBs. This isn't to say
that this is a bad thing, or a good thing for that matter, it's
merely an observation that there are differences between relational
and object technologies.
Scott W. Ambler
>p.s. One thing I'd like to start discussing, perhaps on this website
>is some nitty gritty details about aspects...if you have used them in
>novel ways (or find their use intriguing to debug or document), I'd
>like to hear about it...and start a dialog. I'm still trying to wrap
>my head around the significance/balance of aspects in a typical IT or
>Enterprise application design
I've been working on how to model aspects, and have come to the
conclusion that text-based descriptions are likely the way to go.
I've experimented with color, and various symbols, but these
approaches didn't really seem to grab me.
As for applying aspects, other than for testing and security access
control I haven't run into any situation where I'd be motivated to
apply the technology.
- Scott
Scott W. Ambler
>Rebecca,
>
> There is a reason the database folk do not like Scott Ambler. And it
>is simply this: His knowledge of data modelling is lacking in many
>fundamental respects, (show any DBA his articles on Agile Data
>Modelling and get their opinion), yet he writes holier than thou
>articles about database professionals asking them to become agile and
>join the "brave new world" of Agile, OO methodology, etc. For him to
>write a book on database refactoring is risible.
And yet, for some reason, the database vendors have been taking my
work very seriously. You may not have noticed, but several prominent
people within the data community, including two people who work in
the tools groups at major DB vendors and another within the Oracle
user group community, wrote forewords for the book. They seemed to
be impressed, so apparently there are some database folk who think my
work is pretty good. So good in fact, that the vendors are starting
work on refactoring tools based on the book.
>No one who has even an inkling of database theory or worked with
>databases for any length of time gives any credence to his views.
Perhaps. You obviously don't know this, but in the early 1990s E.F.
Codd approached me to work through some ideas with him regarding
object technology and more specifically object database
technology. Codd, as you know, has done a bit of work in relational
theory and he seemed to respect my views.
> Only
>those people who grew up with C/C++/Java/C# or without any background
>in relational theory will buy his database books.
Actually, that doesn't seem to be the case either, but thank you for
sharing your opinion.
> Any database
>professional will read his books and understand that the author has
>nothing worthwhile to say, in fact, that the author's lack of knowledge
>of this field is amazing.
Have you even read Refactoring Databases? I suspect not. Thank you
for attacking me instead of trying to have a discussion.
> See the comments at
>http://www.dbdebunk.com/page/page/1514543.htm and his articles on UML
>data modelling.
Fabian Pascal is clearly entitled to his opinions. However, In
December the OMG put out an RFP for adding data models to the UML
(see http://www.omg.org/cgi-bin/doc?ab/05-12-02 ). For some
inexplicable reason, organizations such as IBM, Sybase, and Oracle
seem to be getting behind the concept (and other companies for that
matter). Perhaps they're motivated by the fact that their CASE tools
offer their own unique approaches to UML data modeling and that their
clients seem to be requesting a standardized approach.
So, either the major RDB vendors aren't up to speed, or perhaps
Pascal's opinion reflects that of a minority of people who aren't
very receptive to change. I don't know.
Furthermore, have you read the article that Pascal wrote? He starts
by stating that he doesn't know the dojo, which is fair, then he
complains about not agreeing with the requirements of the domain
which he doesn't know anything about. Interesting, but not exactly relevant.
He then discusses an example of capturing people's email addresses,
but he works under the false assumption that you need everyone's
email in the first place. Believe me, you can easily teach karate
without knowing someone's email address. In fact, you can still do
so even if you have the wrong email address. He also misdirects
people by complaining about services that shut down because they
don't have the correct data. Do you really think that a karate
Sensei would refuse to teach someone because he doesn't know your
email address?
The focus of the article, which Pascal seems to have missed, is on
practical techniques for building software. It's not about
relational theory, which is what he was ranting about. Pascal,
unfortunately, likes to misrepresent and misquote the work of other
people. For all his rhetoric about being able to think things
through, his opinion piece on agile data modeling is obviously
shabby. Sadly, he doesn't even have the integrity to provide a link
to the material that he quotes, which would enable his readers to
actually formulate an opinion based on the material in the context
that it's presented. If you like, please read over
http://www.agiledata.org/essays/agileDataModeling.html and view the
actual source material for yourself. You might also want to read
over the series of articles that I wrote for Software Development,
linked to in that article, where I approach the problem without
Pascal also likes to denigrate other people, as you can see in his
comment at the bottom of the article. He makes these comments
without knowing the person nor their background, nor does he even
have the courage to inform them when he's done so. He's very lucky
that nobody has sued him for slander.
>The first question one asks of the UML data modelling articles is,
>"What does UML add to data modelling?" The clear answer is, "Nothing."
Actually, if you were to read
http://www.agiledata.org/essays/umlDataModelingProfile.html a fair
bit, which the OMG and several relational modeling tool vendors seem
to also think.
>So what is the author talking about? It seems he wants to use UML as
>the "tool" to do data modelling! Now, UML in this case just becomes a
>tool to do data modelling, just like Oracle Designer, ERWin, etc. Has
>anything new been added to the body of knowledge regarding data
>modelling? No.
With respect to the UML data modeling profile, my goal was never to
try to add to the body of knowledge regarding data modeling. Where
do I claim that? Why do you feel the need to misrepresent my work?
The goals are:
1. To provide a common, standard notation for data modeling. The
data community should have done this, but never did. There are many
"standards".
2. To put data modeling on the radar scope of object professionals.
3. To define a common approach for tool vendors. Assuming they can
agree to a standard, and I'm not saying that's guaranteed, then the
opportunity for significantly better tool integration exists.
We'll have to see how this plays out over time, but from what I can
see the idea has garnered significant support amongst vendors.
>Yet, Scott continues to flaunt his contributions to "UML
>Data Modelling" as examples of his contributions to the field! If this
>does not showcase his lack of knowledge, what does?
Apparently many of the RDB vendors think otherwise.
> Everyone knows it
>is essentially trivial to learn how to use a tool to do certain things.
>Somebody who writes articles on how to use Eclipse with JSP pages
>usually does not claim that this makes him an expert on OO philosophy!
>Likewise, writing articles on UML data modelling and Agile data
>modelling (whatever that is!) does not make one an expert in relational
>theory or data modelling
Once again, thank you for misrepresenting my work. Please point out
to the people on this list where I have claimed to be an expert on
relational theory?
And, considering the popularity of my writings on data modeling,
there seems to be a very large number of people out there who seem to
think that I have something valuable to say on the subject.
>.
>
>Hence, when news comes out that Scott Ambler has written a book on
>"Database Refactorings", the knowledgeable database professional can
>only laugh and marvel at the fact that there are people willing to
>invest the time to read it!
So what are you saying, that a "knowledgeable database professional"
will choose to remain ignorant of new techniques? Perhaps that
reveals why many application developers don't like working with such people?
>Notice, by the way that he has not answered the question of uni- and b-
>directional mapping raised by remco.greve (#8 post above). He can not
>provide any convincing answer to this issue.
Actually, I already did in another email.
>Read his articles on agile data modelling and note the condescending
>tone that he takes towards data professionals. His tone is apparent in
>many of his database related articles. So, I can understand why Ravi
>criticizes his articles related to databases and relational theory. I
>did not see Ravi criticize any other non-database realted articles.
Perhaps I find many data professionals tedious to interact with. Why
do you suppose that is?
>Notice also Scott's rude tone in the posts and his statements
>constantly flaunting his "author"ity without providing any defence of
>the criticisms.
Thank you once again for misrepresenting what I've written. I've
gone out of my way to respond to the criticism, even the incredibly
rude ones made by you an Ravi.
>And essentially stating that only those who have
>published books can argue with him.
I never once stated, nor implied that. You're the one that's been
ranting about the various authors on this list, not me.
> His constant references to himself
>as an author; and, in a crowing tone, asking Ravi to point out his
>writings before he can discuss anything with him are examplars of
>Scott's style.
When Ravi made sweeping statements about my work, then yes, I asked
him whether he had provided anything of value to the community. From
what I can tell, apparently he hasn't. Ravi was shooting his mouth
off about how smart he was, and how ignorant I was, yet for all his
apparent greatness he's never made the effort to publish
anything. The point, which both you and he seemed to have missed, is
that not only was his attack on my work incredibly rude an
inappropriate, it was doubly so considering he has apparently never
chosen to risk putting his ideas out there for others to consider as
I have done. He should first contribute something to the community,
and then, if he feels the need to do so he can then attack the work
of others. That way he also risks his work being examined as well.
Tim, instead of attacking me and my work, why don't you instead step
up and contribute something to the community? You seem to question
agile approaches to database development. Why don't you try to write
a polite, coherent argument supporting your beliefs and then submit
it to Mark for potential inclusion in his Objective View newsletter?
remco...@gmail.com
not inversible ?) relation that exists outside your object oriented
theory. I was not very clear because i just wrote some things that
came to me at that moment and also english is not my language. Your
example was the relation knows between "senior management"and the fact
"is on the fast track" the inverse relation is clearly "is known by" so
that was not a very clear example. You must note that for my example i
had very specific restictions on the relation and the inverse relation
they had to be functions. You did not exacly confince me that a non
invertable relation (uni-directional) has really any meaning that i
can understand.
markcol...@gmail.com
I saw Ravi make a claim that Scott's argument was not based on facts.
He later gave enough reasons to make one think about Scott's
competence.
If you throw enough mud...
***
Mark Collins-Cope
Scott W. Ambler
>We were talking theory we were looking voor a uni-directional (meaning
>not inversible ?) relation that exists outside your object oriented
>theory.
In OO a uni-directional relationship is something that can be
travelled in one direction. This is typically implemented via an
object reference, e.g. a Person object has a reference to an Address
object. For the relationship to be bi-directional, the Address
object would have to have a reference to the Person object as
well. Another way to implement a bi-directional relationship is via
an intermediary object (similar conceptually to an associative table
in an RDB).
> I was not very clear because i just wrote some things that
>came to me at that moment and also english is not my language.
Not a problem.
> Your
>example was the relation knows between "senior management"and the fact
>"is on the fast track" the inverse relation is clearly "is known by" so
>that was not a very clear example.
The inverse relationship would in fact be "is known by" (or something
similarly named). The point is that in an RDB the relationship is
automatically bi-directional due to the nature of the technology --
relationships are implemented by foreign keys.
In an object schema this is not automatically the case. The
relationship could in fact be maintained only in one direction.
> You must note that for my example i
>had very specific restictions on the relation and the inverse relation
>they had to be functions. You did not exacly confince me that a non
>invertable relation (uni-directional) has really any meaning that i
>can understand.
Do you do any OO programming at all? From a theoretical point of
view, I can see how it would be confusing. You need to actually get
your hands dirty and write some code to see how you'd apply this in practice.
I've got a detailed write up of the concept on IBM Developerworks at
http://www-128.ibm.com/developerworks/webservices/library/ws-tip-implor/
. The example shows a class model and some simple Java code that you
could take a look at.
remco...@gmail.com
speech confusion thing . I think what you call a relalation I call a
aggregation and just to be safe in a relational database i understand
a relation is the same as a table.
Scott W. Ambler
David Allen
wrote:
> A year ago
> I took a foray into rule based systems and how they
> could be
> integrated into oo applications...that was
> interesting...any time
> someone wants to talk about rules engines meets oo
> design, well, give
> me a holler........
I'm interested in rule-based systems, but I've not yet
integrated them with my day-to-day software designs.
(At least I have not yet implemented the business
rules as "business rules" in a formal sense)
I work for a college, developing your typical
enterprise web-based applications
in an object-oriented language.
What I've noticed over the years is that I sit in
meetings with my users, gathering requirements, and
writing code to implement them.
Many times, you could characterize a requirement as a
business rule.
That business rule is expressed in code. Good design
principles (like "one rule -- one place") encourage me
to implement the business rule in a single class, so
that when the rule changes, it is easy to find and
change the corresponding code. Or in other words, I
make that class responsible for executing whatever is
necessary to implement the customer's business rule.
This is basic stuff.
The interesting part that I want to get feedback on
has to do with the visibility of this rule in the
system from the user's point of view.
Once I've written down the rule and coded the
application, and the users have tested it, we forget
about it.
If it is a rule that is inherent to their daily
activities, and they use this system on a daily basis,
then they will intuitively remember how the software
behaves.
But if we have coded a screen that they use once a
year, which is very common for business processes that
operate on an annual cycle, then they sometimes
forget. They call me and ask "Now how did we design
the software to act in this case?"
I find that I have to interrupt my current activity,
go back and examine the source code, figure out what
it is going to do, then communicate that back to the
user.
The most obvious solution I have found to this is to
redesign the user interface to more clearly express
what is going to happen when they click on a checkbox
or press a button. Sometimes I simply add a bit of
text to the page, explaining what is going to happen
when they click on this button every January. All
this seems to be part of the art of designing usable
interface and I have not seen much written on this, so
if you have any references please feel free to share
them.
But back to the reason I responded to Rebecca's
e-mail:
In some cases, I gather a large number of similar or
related rules, which may change over time.
The case has not arisen many times for me, but when it
does, the possibility of using a rules engine pops
into my head.
It seems to me, that the advantage of an interactive
rules engine in such cases would be that the rules
would be clearly visible to the users, and they could
change them within some limited range.
Lets take a concrete example for conversation.
Lets say we want to add a security subsystem to our
application that allows users to specify roles and
permissions for the users of the system. That seems,
we have to do this for every single application that
we create.
In my first attempt at this, I might simply design an
elegant object-oriented design, and code the system to
use it. The shortcoming of course would be that these
rules would be invisible, and users would have to call
me to find out what the rules were.
In my second attempt, trying to honor the principle of
"make rules visible and understandable",
I might design a fixed set of roles and permissions,
present them in a grid with little checkboxes, and
allow the user to click on things to change the types
of permissions are granted to various roles. This
would be a great way to allow the user some
flexibility and to make the rules visible to the users
at all times.
Now let's assume that we have the additional
requirement for user-controlled modification of the
roles and permissions.
In my response to this, I might make a user interface
that would allow the users to create new roles, create
new permissions, and combine them. That we retain a
little grid of checkboxes, this system should remain
easy to understand and use.
But what if the requirements are even trickier than
this and we need a more versatile system?
We might build a little rules based engine which would
allow the users to create security rules that combine
roles and permissions. This approach actually seems
pretty cool, doesn't it? And with the rules based
engine, the users can always see their rules and so we
would seem to be preserving rules visibility. The
downside here it is that if the rules engine permits
rules that are too complex, then although the users
may be able to see the rules, they may not actually be
able to understand the implications of what they have
done.
Start for the long e-mail, but I wanted to give you
the full business context.
If any of you have any references to resources that
address situations like this, where I could get some
further depth, I would be grateful.
I'm especially interested to know whether others have
thought about or written about this notion of taking
the customer's business rules, which are hidden inside
the code, and designing the system in such a way as to
make those rules more visible so that the system is
more easily understood by its users. As I mentioned,
this visibility and understandability is especially
important in when the user interface is visited only
once in a great while, or in cases where there is
rapid staff turnover.
David Kreth Allen
Web Developer
Carlson School of Management
University of Minnesota
Scott W. Ambler
>Yes I do object oriented programming. It think we are just in a kind of
> speech confusion thing .
In the OO world relationships are often categorized as associations,
aggregations, or compositions. I was talking about relationships in general.
> I think what you call a relalation I call a
>aggregation and just to be safe in a relational database i understand
>a relation is the same as a table.
At the physical RDB level there are tables. Rows within tables may
have relationships to other rows.
In relational theory there are relations and tuples (and other
concepts of course).
My focus is on practice, not theory.
Scott W. Ambler
><snip>
>But if we have coded a screen that they use once a
>year, which is very common for business processes that
>operate on an annual cycle, then they sometimes
>forget. They call me and ask "Now how did we design
>the software to act in this case?"
>I find that I have to interrupt my current activity,
>go back and examine the source code, figure out what
>it is going to do, then communicate that back to the
>user.
This is probably a good indication that you need some user
documentation, perhaps a help screen, explaining this. Particularly
if the cost of writing the documentation once is lower than having
you get into the code. One approach might be to wait for questions
like this, write up the answer, and put it in the documentation at
that point. Something simply like an FAQ or Wiki might do it for you.
>The most obvious solution I have found to this is to
>redesign the user interface to more clearly express
>what is going to happen when they click on a checkbox
>or press a button. Sometimes I simply add a bit of
>text to the page, explaining what is going to happen
>when they click on this button every January. All
>this seems to be part of the art of designing usable
>interface and I have not seen much written on this, so
>if you have any references please feel free to share
>them.
There's a fair bit out there on usability and UI design. Here's a
good list (IMHO):
http://www.foruse.com/publications/bibliographies/recommended.htm
><snip>
>Now let's assume that we have the additional
>requirement for user-controlled modification of the
>roles and permissions.
You'd want to limit this to people with the knowledge and skills to do so.
>In my response to this, I might make a user interface
>that would allow the users to create new roles, create
>new permissions, and combine them. That we retain a
>little grid of checkboxes, this system should remain
>easy to understand and use.
>
>But what if the requirements are even trickier than
>this and we need a more versatile system?
I would count on this. The challenge with business rules is that
there is a wide range of them, security rules as in your example,
data integrity rules, and algorithms come to mind. That list clearly
isn't complete. Depending on the situation, you want to implement
the rule in the appropriate place. For example, a data integrity
rule is likely best implemented in the DB, not a rules engine.
>We might build a little rules based engine which would
>allow the users to create security rules that combine
>roles and permissions. This approach actually seems
>pretty cool, doesn't it? And with the rules based
>engine, the users can always see their rules and so we
>would seem to be preserving rules visibility. The
>downside here it is that if the rules engine permits
>rules that are too complex, then although the users
>may be able to see the rules, they may not actually be
>able to understand the implications of what they have
>done.
Yep, world's tough like that. When COBOL first came out the vision
was that business people could use it to write their own
software. Didn't seem to work out that way in practice though.
>Start for the long e-mail, but I wanted to give you
>the full business context.
>If any of you have any references to resources that
>address situations like this, where I could get some
>further depth, I would be grateful.
>I'm especially interested to know whether others have
>thought about or written about this notion of taking
>the customer's business rules, which are hidden inside
>the code, and designing the system in such a way as to
>make those rules more visible so that the system is
>more easily understood by its users. As I mentioned,
>this visibility and understandability is especially
>important in when the user interface is visited only
>once in a great while, or in cases where there is
>rapid staff turnover.
Reducing coupling, increasing cohesion, and improving usability are
always good ideas in my mind. :-)
remco...@gmail.com
were you actualy meaning?
remco...@gmail.com
there is also in object orientated programming the relation inherits
(and the inverse is inherited by) and the inverse relationship of
agragated (agregated by) making agragation and composition and
inheritance special kinds of relationships. When i look at personal
relationships modeling relationships like that is like saying Jan loves
Truus and the inverse relationship is Truus loves Jan but it is not the
inverse relationship is Truus is loved by Jan .is that not the
confusion that excists in oo modeling.
Scott W. Ambler
- Scott
At 01:55 PM 4/1/2006, you wrote:
>So when you said "Perhaps because you want to model reality? " what
>were you actualy meaning?
In the real world uni-directional relationships exist. If you're
interested in modeling the actual domain concepts, then you need the
concept of uni-directional relationships in your modeling language.
At 02:30 PM 4/1/2006, you wrote:
>Also when speaking of " relationships in general. " is it not so that
>there is also in object orientated programming the relation inherits
Yes, there is an inheritance/subtyping relationship. That's often
considered a different concept than
association/aggregation/composition though.
>(and the inverse is inherited by) and the inverse relationship of
>agragated (agregated by) making agragation and composition and
>inheritance special kinds of relationships.
Yes and no. Aggregation and composition are though of as special
types of association.
One what to think of it is that Inheritance and Association are
subtypes of Relationship, Aggregation is a subtype of Association,
and Composition is a strong form of Aggregation. I cover these
concepts in detail in The Object Primer 3rd Edition
(www.ambysoft.com/books/theObjectPrimer.html), although if you were
to go poking around the web a bit I bet you could find a multitude of
articles on the subject. Or, you could download the UML
Specification from www.omg.com and wade through that.
> When i look at personal
>relationships modeling relationships like that is like saying Jan loves
>Truus and the inverse relationship is Truus loves Jan but it is not the
>inverse relationship is Truus is loved by Jan .is that not the
>confusion that excists in oo modeling.
The confusion would only be on the part of the modeler, they'd need
to know how to capture the concept using the tools at hand.
But, as I've pointed out earlier, my original statement was not about
modeling it was about implementation. RDB technology doesn't allow
you to natively implement a uni-directional association. That's not
good nor bad per se, it's just an observation. Similarly, object
technology doesn't natively support set-based queries, although
relational technology does. Yes, there are object-relational
databases out there which try to implement the best of both worlds,
or perhaps the worst of both worlds depending on your point of view,
which can do both of these things.
Ken Pugh
This mailing list has started out weird. I was put onto a mailing
list. I have no idea of who else is on it. The first message I
received was what I would deem confrontational.
I'm a fan of mailing lists for exchanging information only. If they
are used for purposes beyond that, I think that the participants
ought to agree on ground rules. For example,, you may refer to an
idea as "stupid" (if you really have to take that tone), but don't
use that term to the person who advocates that idea. If you really
think an idea is bad, then show the reasons with logic, not
harangue. The former helps us all learn, the latter distracts us
from learning.
I'm not a database expert, so I'm not really sure what the discussion
is all about. Let me offer an example, and then someone can tell me
if the example is right, wrong, off-base, or whatever.
Let's suppose that we have Cars that have multiple Owners. Now with
objects, you might represent this as:
class Car
Owners [] owners
class Owner
Note that Owner has no knowledge of the Cars that they own. One
Owner can own multiple cars. But that's not of interest to our
application, so we don't need the reverse, e.g:
class Owner
Car [] cars
In a database, you might structure the relationship with two tables:
Car
ID
Model
CarOwner
Car.ID
OwnerName
OwnerAddress
But since an Owner can own multiple cars, you'd probably structure it
with three tables.
Car
ID
Model
Owner
ID
Name
Address
CarOwner
Car.ID
Owner.ID
This structure can handle both a one-to-many relationship and a
many-to-many relationship. CarOwner yields both Owners for a Car and
Cars for an Owner. Even if you didn't need to know what Cars an Owner
owned, the information is already be there
Is this what you guys are talking about when you say uni and bi?
Ken
Scott W. Ambler
>Is this what you guys are talking about when you say uni and bi?
That's the sort of thing that I was talking about.
BTW, a sample set of mailing list rules can be found at
http://www.agilemodeling.com/feedback.htm#Rules . Mark, feel free to
adopt and then change whatever you like.
- Scott
remco...@gmail.com
they exists. I think even the concept of direction when speaking about
"real world relations" is nonsense.
remco...@gmail.com
it is not.
First your relations are not the same as my relations. I see 3
relations here Car Owner and CarOwner you can make even more relations
by joining them. Second if you model it like Scott proposes then there
is no difference the relation still exists even if you do not define it
or know that it exists you can device a algorithm to find them. The
difference between a relational database and objects is that the
"relations" between entities exists in a relational database because of
the structure of the data and by objects you have to make it explicit
not making it explicit does not mean it does not exist.
remco...@gmail.com
assumed a closed world?
Scott W. Ambler
Oh well, you're definitely entitled to your opinion. We've provided
you with several very straightforward examples, if you choose to
disagree then that's your prerogative.
If you don't believe that uni-directional relationships exist then
whether or not RDBs can implement them natively shouldn't really be
an issue for you, so don't worry about it.
Scott W. Ambler
>"Is this what you guys are talking about when you say uni and bi? ". No
>it is not.
>First your relations are not the same as my relations. I see 3
>relations here Car Owner and CarOwner you can make even more relations
>by joining them.
Remember that we're talking about relationships, not the theory
concept of relations.
Also, the fact that you can join the tables to get more than we
originally wanted based goes towards the original discussion point
that there is a difference between RDB technology and OO technology.
>Second if you model it like Scott proposes then there
>is no difference the relation still exists even if you do not define it
>or know that it exists you can device a algorithm to find them. The
>difference between a relational database and objects is that the
>"relations" between entities exists in a relational database because of
>the structure of the data and by objects you have to make it explicit
>not making it explicit does not mean it does not exist.
Absolutely. But, if you go back and actually read the my original
passage that Pascal had quoted out of context, you'll discover that I
wasn't discussing relations. I had actually made an off-hand comment
about the differences between OO and RDB technology. That's it. His
purposeful misrepresentation of my writings has now gotten you worked
up over a relatively trivial issue that was inconsequential to the
actual article (the topic of the article,
http://www.agiledata.org/essays/mappingObjects.html , was O/R mapping
strategies, not relational theory).
>Or is it a open world vs closed world thing we are talking about? I
>assumed a closed world?
Interesting question. Why do you think that's important?
- Scott
remco...@gmail.com
whether or not RDBs can implement them natively shouldn't really be
. What i do worry about is that you believe that you have given
straightforward examples of unidirectional relations in the real world.
Scott W. Ambler
Oh well, then have fun worrying.
IMHO, both myself and Ken have provided what we feel to be realistic
and straightforward examples of actual, real-world uni-directional
relationships. I'm sorry if you're not happy with our explanations.
Also, please note the use of the word relationship, not relation.
remco...@gmail.com
remco...@gmail.com
being a author and all.
Scott W. Ambler
>I can only hope that you are not to happy with with your explanations
>being a author and all.
I'm more than satisfied with my answers because they were very clear
and straightforward in my opinion. You chose not to accept them, but
that's your decision.
remco...@gmail.com
I think i am resonably able to objectively judge if it was a clear
explanation or not.
Tim
Remco, Scott Ambler believes he is always right. There is no point in
you (or anybody else) having discussions with him. Fabian Pascal was
right to point out the article titled "Ignorant and Unaware of it" at
his web site (www.dbdebunk.com).
Mark, does that deserve a boot from this group?
Do tell me, please. LoL.
What a joke this group of self-styled authors is! It is extremely funny
to see Scott say something and expect it to be swallowed without
questioning, simply claiming that he explained it to his own
satisfaction.
Scott, in case you did not realize, the point of a public discussion is
to convince others, not to convinve yourself. When somebody says that
they are not convinced, the usual thing to do is to give another
example that may help explain it.
But I am afraid Scott cannot do that since there is no such thing as a
uni-directional relationship in the sense Scott is talking about.
More and more, it looks like Ravi's original opinion of Scott was
correct, after all.
Tim
Tim
afraid that you will be very busy in the coming days!
Tim
Ken Pugh
>p.s. One thing I'd like to start discussing, perhaps on this website
>is some nitty gritty details about aspects...if you have used them in
>novel ways (or find their use intriguing to debug or document), I'd
>like to hear about it...and start a dialog. I'm still trying to wrap
>my head around the significance/balance of aspects in a typical IT or
>Enterprise application design
I've looked as aspects, but haven't used them. The place that I see
them very useful is in adding some standard features without having
to alter existing code. Security checks, logging, and contract
checking come to mind.
However, it would seem to me the more specific you make an aspect
(e.g. contract checking), the more you create two sets of code to
maintain - the original method and the aspect which checks that
method. So more general aspects, which can apply more across the
board, such as security, seem to be a sweet spot. Logging also would
be a sweet spot, unless you started to need much more specific log
formatting on each particular method call.
There are some other frameworks that have many of the aspects of
aspects. For example, struts allows you to check for security in one
place before executing a servlet. nContract allows you to add
contract checking to existing C# code.
Ken
Scott W. Ambler
<snip>
>However, it would seem to me the more specific you make an aspect
>(e.g. contract checking), the more you create two sets of code to
>maintain - the original method and the aspect which checks that
>method. So more general aspects, which can apply more across the
>board, such as security, seem to be a sweet spot. Logging also would
>be a sweet spot, unless you started to need much more specific log
>formatting on each particular method call.
I agree. The more specific the aspect, the more motivated you would
be to simply develop a component and then simply invoke the
functionality directly. AOP definitely seems good for the general
cases that you suggest.
However, one complaint that I have heard from people is that it can
be hard for people to comprehend the code. The basic concern is that
they write the normal OO code in one place, then either they or
someone else writes the aspect code in another place which affects
the functionality which they just coded.
On the other hand, that's exactly the sort of thing that I would like
to do to test code sometimes. Tradeoffs, gotta love them.
Tim
I looked at the reviews for "Prefactoring" at the amazon web site.
Amazing. Of 13 reviews, three gave it a five star!. The rest gave it
less, some as low as one.
Guess who gave it three stars? You are right - two other people (Scott
W. Ambler and Mark Collins-Cape, both authors/contributors to the
ObjectView magazine.), and some group called the Midwest Book Review.
Nobody else felt it deserved five stars. Most were quite critical.
This point is not about the merits of the book, but to point out that
the closing of the ranks by these authors seems a common trend.
The logical conclusion would be to discount anything that one author
says in support of another as a case of "You scratch my back, I'll
scratch yours".
Mark Collins-Cope, have I pointed out enough facts to be considered
rude and booted from this group? Please let me know. Or are you too
busy writing one more glowing review for another of your confreres?
Tim
Tim
Did any of you have the chance to read the article that Ravi
criticized?http://www.ratio.co.uk/ov9pdf.pdf
If you did not have a chance to do so, here is the quote from the
"venerable" incorrigibly rude Scott Ambler's first response,
"Ravi, assuming that you're talking about my Glacial Methodology
article in the most recent version of OV it was meant as an April
Fool's joke and wasn't meant to be taken seriously.
For anyone interested, a more thorough description can be found at
http://www.ambysoft.com/essays/glacialMethodology.html "
Once you read that article, and have read more of the Great Scott's
agileDBA articles, you'll see how rude and classless this man is. If
you have a background in relational theory or databases, you'll see
that what he criticizes is not what actually happens in any project.
Hence Ravi's statements that Scott Ambler sets up strawmen, demolishes
them and claims all data professinals are dinosaurs.
Scott owes Ravi and the data professionals a serious apology.
Tim
markcol...@gmail.com
Guess who gave it three stars? You are right - two other people (Scott
W. Ambler and Mark Collins-Cape, both authors/contributors to the
ObjectView magazine.), and some group called the Midwest Book Review.
Nobody else felt it deserved five stars. Most were quite critical.
This point is not about the merits of the book, but to point out that
the closing of the ranks by these authors seems a common trend.
All the authors have spent a long time thinking about OO related problems. That's probably their common connnection and also why they have similar perspectives on things.
I invited Ken to write a piece in ObjectiveView after I had reviewed his book and written the amazon review - specifically because of some of the negative reviews from the more fragile agile of the community. I've never met Ken (though would like to), and met Scott once 8 years ago.
So your logical conclusions are incorrect - tho' I can see why you perhaps thought them.
says in support of another as a case of "You scratch my back, I'll
scratch yours".
Mark Collins-Cope, have I pointed out enough facts to be considered
rude and booted from this group? Please let me know. Or are you too
busy writing one more glowing review for another of your confreres?
Tim,
To be quite honest you're wasting your finger energy trying to wind me up. I don't know what the rest of the group think (please chip in) - but it certainly appears to me you are trying very hard to get kicked off. I'm going to post some group rules soon. I don't understand why.
I'd also appreciate any feedback from the rest of the group on my decision to ban Ravi (on the grounds he was deliberately offensive, then continued to be so after a warning - despite my efforts to talk him round).
You are, however, welcome to become one of the authors in ObjectiveView - and take the risk of putting pen to paper. Feel free to discuss any topics you'd like to contribute with me - or the group.
Regards,
Mark.
Scott W. Ambler
>Ken,
>
> I looked at the reviews for "Prefactoring" at the amazon web site.
>Amazing. Of 13 reviews, three gave it a five star!. The rest gave it
>less, some as low as one.
I just went back and read those reviews. Did you realize that
several of the low reviews were written by people who obviously
hadn't even read the book? They were ranting about Ken not
understanding refactoring, yet his definition was spot on. But, even
if you don't agree with that, there's still the fact that several
people who are very knowledgeable about refactoring were reviewers of
the book. This included Martin Fowler, who IMHO seems to know a
thing or two about refactoring.
Like it or not, Prefactoring won the 2005 Jolt Award a couple of
weeks ago at the Software Development conference. Apparently, a
panel of independent judges choose it from a collection of the best
books published last year.
>Guess who gave it three stars? You are right - two other people (Scott
>W. Ambler and Mark Collins-Cape, both authors/contributors to the
>ObjectView magazine.), and some group called the Midwest Book Review.
>Nobody else felt it deserved five stars. Most were quite critical.
Most seemed to be cranks who were more intent on attacking Ken's book
instead of actually reviewing it fairly.
>This point is not about the merits of the book, but to point out that
>the closing of the ranks by these authors seems a common trend.
Sounds like a conspiracy to me! We should get Mulder and Sculley on
this right away.
>The logical conclusion would be to discount anything that one author
>says in support of another as a case of "You scratch my back, I'll
>scratch yours".
>
> Mark Collins-Cope, have I pointed out enough facts to be considered
>rude and booted from this group? Please let me know. Or are you too
>busy writing one more glowing review for another of your confreres?
I suspect that you've made enough personal attacks to get yourself
booted off. Why are you constantly egging Mark on to ban you? Is
your goal to continue to be rude so that you get booted off, enabling
you to whine to all your friends how evil Mark is?
Tim, the rest of us are trying to have a polite conversation so that
we can learn from each other. You've been made welcome on this list
even though your track record to date has been quite spotty.
Mark, and frankly everybody else on this list, have been very patient
with you and yet you repay them with personal attacks. Ken has spent
considerable time trying to help Remco understand the differences
between RDB and object technology, as have I. Please stop
contributing negatively and instead make an attempt to contribute positively.
markcol...@gmail.com
Did any of you have the chance to read the article that Ravi
criticized?http://www.ratio.co.uk/ov9pdf.pdf
"Ravi, assuming that you're talking about my Glacial Methodology
article in the most recent version of OV it was meant as an April
Fool's joke and wasn't meant to be taken seriously.
For anyone interested, a more thorough description can be found at
http://www.ambysoft.com/essays/glacialMethodology.html "
Once you read that article, and have read more of the Great Scott's
agileDBA articles, you'll see how rude and classless this man is.
Was Scott rude in the article then? I didn't notice it. I don't understand your point, Tim.
you have a background in relational theory or databases, you'll see
that what he criticizes is not what actually happens in any project.
And Tim, do you have exposure to a large number of projects? Do you do external consulting with many different companies? If not, I suspect your view of the "whole world" is limited (this is, of course, true of many of us).
Mark.
Scott W. Ambler
>I invited Ken to write a piece in ObjectiveView after I had reviewed
>his book and written the amazon review - specifically because of
>some of the negative reviews from the more fragile agile of the
>community. I've never met Ken (though would like to), and met Scott
>once 8 years ago.
I was a tech reviewer for Ken's book, one of many in fact. The
publisher, O'Reilly, sent me a copy once it was published in the hope
that I would write a review for it. I'm sent between 10 and 15 books
a month by various publishers, so apparently the publishing houses
are all in on the conspiracy. At that point I actually put it on the
stack of "to read" books, sorry Ken, with the intention of getting to
it when I get to it. Then, when the book made the short list in the
Jolt award process, which no mean feat, the magazine asked me to
write up a short review of it in case it won an award (egads, the
plot thickens, now the magazine industry is in on it too). Software
Development (www.sdmagazine.com) does this for all of the finalists
so that word isn't leaked about who the actual winners are until the
night of the award ceremony. They also need the write-ups in time
for the upcoming issue, so they can't afford to wait to get the write
ups until after the ceremony.
So, considering I had already done the work to write up the review
for the magazine, I thought I had might as well rework it for Amazon.
Tim, have you actually read Ken's book?
Tim
Here is the first email you sent to Ravi:
-----------------------------------------------------------------------------------------------------------------
Please desist from name calling in this group. If you can't resist it,
I can
recommend some school playgrounds where it is considered an acceptable
way
of conducting yourself. Here it is not. I won't warn you again.
Mark Collins-Cope.
------------------------------------------------------------------------------------------------------------------
The reference to school playgrounds is taunting and rude. You
yourself were rude. How would you recognize if Scott Ambler was rude? I
can give you examples: Here's what Scott said in his first response:
"Have you ever written anything on this subject? Or do you just snipe
at other people without actually contributing anything to the
community?"
And without any justification, "Ravi, I suspect that somebody involved
in this conversation is an ignoramus. I don't think that it's me
though. "
While Ravi did provide justification for calling Scott an ignoramus as
far as database theory was concerned, Scott just called Ravi an
ignoramus for disagreeing with him.
Can I expect an apology from Scott to Ravi? or an acceptance from you
that your first email to Ravi was rude? And a public chastisement for
Scott Ambler? Or will you authors/contributors close ranks and chant in
unison, "Ravi is rude! Ambler is great!"? (How does taunting feel, now,
Mr. Mark Collins-Cope?)
I can go through his postings and point out many instances where Scott
was rude, never answered questions posed, yet kept claimning that he
was right because he was an "author" with his own web-site. It's simply
not worth the trouble.
Re the original article on Glacial Methodology: The sarcastic
references to 67th normal form and 74th normal form were insulting. As
Chris Date has shown, for practical purposes there can be no more than
6 normal forms. I've been on about 15-20 projects as a database
specialist, working on the East coast and the West Coast, and other
countries, too, but never have I seen what Ambler describes, never. As
OO people your outside view may not be correct. If I were to write that
in all OO projects, people consult Ouija boards to do CRC diagrams,
would you not be offended? Ambler's comments are akin to that.
Incidentally, Scott Ambler's articles on Agile Data Modelling were
initially observed by Chris Date to be trash and passed on to Fabian
Pascal to criticize, which he duly did. See
http://www.tdan.com/sms_issue30.htm
Hence, when Ravi criticizes Scott Ambler's lack of knowledge of
database fundamentals, he is in good company. Currently, Chris Date is
the leading authority on Relational Theory. If he says Scott Ambler
does not know what he is talking about, that is good enough for me.
Tim
Scott W. Ambler
>"Have you ever written anything on this subject? Or do you just snipe
>at other people without actually contributing anything to the
>community?"
Actually, if you hadn't quoted that out of context, you'd see that
Ravi's unprovoked attack was quite rude and sniping.
>And without any justification, "Ravi, I suspect that somebody involved
>in this conversation is an ignoramus. I don't think that it's me
>though. "
Once again, out of context. I responded after Ravi had accused me of
being ignorant. If you actually read the article he was ranting
about, you would see that it had nothing to do with relational
theory, which is what he was accusing me of being ignorant
of. Regardless, it was inappropriate to act the way that he did.
>While Ravi did provide justification for calling Scott an ignoramus as
>far as database theory was concerned, Scott just called Ravi an
>ignoramus for disagreeing with him.
Actually, I implied that he might be the ignorant one considering the
way that he was acting.
>Can I expect an apology from Scott to Ravi?
No, I have nothing to apologize for.
>or an acceptance from you
>that your first email to Ravi was rude? And a public chastisement for
>Scott Ambler? Or will you authors/contributors close ranks and chant in
>unison, "Ravi is rude! Ambler is great!"? (How does taunting feel, now,
>Mr. Mark Collins-Cope?)
You seem to be the only one chanting that Tim. And I'm the one
accused of putting up strawmen?
>I can go through his postings and point out many instances where Scott
>was rude,
Tim, I've been incredibly polite when it comes to you and Ravi.
> never answered questions posed,
I've answered many questions. Many of the rude ones I've
ignored. I've also ignored several of Remco's questions once it was
clear he wasn't conducive to the answer I was providing. I was
talking about RDB and OO practice, he wanted to talk about
theory. Sorry, but the original article focused on practice, and my
answer, which in fact is 100% accurate when it comes to RDB and OO
technology, also focused on practice. I'm not beholden to Remco for
making him feel good about the answers I provide.
> yet kept claimning that he
>was right because he was an "author" with his own web-site.
I never once claimed that I was right because I was an author with my
own web site. Please back up your accusations with actual evidence,
or please stop slandering me.
> It's simply
>not worth the trouble.
Then why do you keep ranting about this?
> Re the original article on Glacial Methodology: The sarcastic
>references to 67th normal form and 74th normal form were insulting.
The article was an April Fool's joke. Lighten up. The reference to
these very obviously ridiculous levels of normalization were put
there to clue people in that it was a joke.
> As
>Chris Date has shown, for practical purposes there can be no more than
>6 normal forms. I've been on about 15-20 projects as a database
>specialist, working on the East coast and the West Coast, and other
>countries, too, but never have I seen what Ambler describes, never. As
>OO people your outside view may not be correct. If I were to write that
>in all OO projects, people consult Ouija boards to do CRC diagrams,
>would you not be offended? Ambler's comments are akin to that.
Tim, I hate to burst your bubble, but I had several requests by large
corporations to come in and train their staff on the Glacial
Method. I even had a request to do a magazine interview on the
method. These people thought that this was a serious methodology, so
apparently I was hitting pretty close to home.
- Scott
====================================================
Scott W. Ambler :-)
Tim
8x--- Snip --
> No, I have nothing to apologize for.
>
You never do, Scott, you never do! And you never will.
8x--- Snip --
> > never answered questions posed,
>
I've also ignored several of Remco's questions once it was
> clear he wasn't conducive to the answer I was providing.
>
Translation: You've failed to convince remco of your viewpoint,
cannot seem to find another example, and seem to have given up.
8x--- Snip --
>
> The article was an April Fool's joke. Lighten up. The reference to
> these very obviously ridiculous levels of normalization were put
> there to clue people in that it was a joke.
8x--- Snip --
>
> Tim, I hate to burst your bubble, but I had several requests by large
> corporations to come in and train their staff on the Glacial
> Method. I even had a request to do a magazine interview on the
> method. These people thought that this was a serious methodology, so
> apparently I was hitting pretty close to home.
>
> - Scott
>
If even people in power cannot understand that the article is a
joke, doesn't it drive home Ravi's point that the average software
developer is incompetent? So was he "foolish" to do so, as you earlier
stated, Scott? You've just proved his point! LoL. (And stating he was
fioolish was a very polite thing to do, wasn' t it? Especially since
that statement was personal and an opinion, not fact! Are you noting
this, Mark?)
And I don't see any support for your position from anybody except
other authors/contributors to the magazine. The common folk seem to
disagree with you.
Tim
markcol...@gmail.com
Please desist from name calling in this group. If you can't resist it,
I canrecommend some school playgrounds where it is considered an acceptable
way of conducting yourself. Here it is not. I won't warn you again.
Mark Collins-Cope.
yourself were rude.
The reference to school playgrounds is indicative of the fact that this type of behaviour is common amoungst small children. I know, my 8 and 9 year olds do it. I'm trying to wean them off it - and I'm not interested in dealing with it here.
How would you recognize if Scott Ambler was rude? I
can give you examples: Here's what Scott said in his first response:
"Have you ever written anything on this subject? Or do you just snipe
at other people without actually contributing anything to the
community?"
While Ravi did provide justification for calling Scott an ignoramus as
far as database theory was concerned, Scott just called Ravi an
ignoramus for disagreeing with him.
What I saw was someone with a preconcieved (third party) notion of what someone else had said, who was not in the slightest bit interested in listening, and only interested in throwing insults.
Can I expect an apology from Scott to Ravi? or an acceptance from you
that your first email to Ravi was rude? And a public chastisement for
Scott Ambler? Or will you authors/contributors close ranks and chant in
unison, "Ravi is rude! Ambler is great!"? (How does taunting feel, now,
Mr. Mark Collins-Cope?)
I don't speak for Scott. I stand by my first email to Ravi - see above.
I doubt anyone is going to chant anything - and if that's "taunting me", feel free to go ahead.
Personally, I don't give a damn.
references to 67th normal form and 74th normal form were insulting. As
Chris Date has shown, for practical purposes there can be no more than
6 normal forms. I've been on about 15-20 projects as a database
specialist, working on the East coast and the West Coast, and other
countries, too, but never have I seen what Ambler describes, never. As
OO people your outside view may not be correct. If I were to write that
in all OO projects, people consult Ouija boards to do CRC diagrams,
would you not be offended? Ambler's comments are akin to that.
I can see the funny side in a lot of things. Even this conversation ;-)! I don't know, perhaps its a British cultural thing?
Also, I've always found that people respect you more if you can take a bit of flack with good humour.
As OO people I'm sure we don't know as much relational theory as database specialists do - the question is - does that matter?. Why don't you educate us in an article? You know, I used to object to postings on OO newsgroups that said things like "ignore relational theory, we have our own body of knowledge", etc. one can always learn from lateral perspectives - and OOAD certainly had some roots in relational practise.
Incidentally, Scott Ambler's articles on Agile Data Modelling were
initially observed by Chris Date to be trash and passed on to Fabian
Pascal to criticize, which he duly did. See
http://www.tdan.com/sms_issue30.htm
Well, we all know your opinion of Scott (and I) now, Tim.
So what do talk about next?
Regards,
Mark.
Scott W. Ambler
>Incidentally, Scott Ambler's articles on Agile Data Modelling were
>initially observed by Chris Date to be trash and passed on to Fabian
>Pascal to criticize, which he duly did. See
>http://www.tdan.com/sms_issue30.htm
And yet many other people think that the article is pretty darn
good. Pascal criticism, if you're actually to read it, is inane. He
complains about disagreeing with the requirements, interesting but it
has nothing to do with the actual technique, and complains about how
difficult it is to collect people's emails after the fact if you
don't get the email column in the database for your first
release. The problem domain was a karate school, and I can safely
tell you that it's possible to teach people karate without knowing
their email address. Furthermore, considering how volatile email
addresses are, and considering that many people don't have them, the
quality of the data in that column will always be questionable at best.
The real issue is that the old guard is threatened by the new
approaches to data-oriented issues. At the Agile Data site,
www.agiledata.org, I overview the basic skills that developers should
have to interact with data professionals effectively, including data
modeling. I also describe techniques, such as agile approaches to
data modeling, database refactoring, and database regression testing,
which enable data professionals to work in an evolutionary
manner. Furthermore, I describe philosophies which would enable data
professionals to become more agile in the way that they work. A fair
bit of my writings on that site focus on how data professionals can
become productive members of agile teams, and frankly I'm one of the
few people in the agile community who is willing to invest time to
help the data community. Most people seem to have written the data
folks off as a lost cause. My personal experience is that data
professionals have significant value to add to a project, I've even
said so at the site and in several books, but that they need to
change the way that they approach their work.
The fundamental challenge is that I've written about techniques which
show that we don't need to adopt the often time consuming and
bureaucratic procedures promoted by the data community. I've worked
in a score of organizations all over the world, and in every single
one of them the data folks were always convinced that they were doing
a pretty good job. It didn't take long to discover that this wasn't
the case at all, that they were doing a questionable job (just look
at the quality of the data in many production data sources), blaming
everyone but themselves, and were more often than not spending more
time politicking than actually working. Personally, I think that the
data community can do a lot better.
At Software Development a few weeks ago I attended Dagna Gaythorpe's
talk entitled something along the lines of "Why Data isn't
Agile". She opened with the anecdote that whenever you approach a
traditional data person the first thing they blurt out is "The answer
is 3 months, no what's the question?" Obviously this is a
caricature, but one that seems to hit pretty close to home
considering how many people chuckled.
>Hence, when Ravi criticizes Scott Ambler's lack of knowledge of
>database fundamentals, he is in good company. Currently, Chris Date is
>the leading authority on Relational Theory. If he says Scott Ambler
>does not know what he is talking about, that is good enough for me.
With all due respect to Chris Date, he doesn't know me, has never
worked with me, nor has he even chosen to engage me in conversation.
Similarly, Fabian Pascal has never worked with me nor does he know
me, and the only conversations I've had with him were inane arguments
(much like the one that Ravi and you have engaged me in, although
amazingly you too have proven more polite than Pascal). Considering
that I don't write about relational theory, it's difficult to imagine
how Pascal could possibly judge my knowledge in that area. When
Pascal wrote that article he didn't contact me at all to discuss the
ideas, he merely criticized.
The article, published at
http://www.agiledata.org/essays/agileDataModeling.html , works
through a case study for how to take an evolutionary approach to data
modeling. The point of the article is to show that it can be done,
that it works, and that in fact it is quite easy if you choose to
work in this manner. Modern software development processes, such as
RUP, XP, FDD, and so on are all evolutionary in nature. If data
professionals want to remain relevant, then they need to start
adopting techniques which enable them to work in an evolutionary
manner. Less theory, and more practice, is the order of the day.
Tim, I suspect that your faith in Pascal is misplaced. You may want
to listen to what he and Date have to say about relational theory,
but when it comes to practice it doesn't seem that Pascal has very
good judgement. Considering that he has to misrepresent my writings,
quote them out of context, and then focus on non-sequiturs in order
to "criticize" my work you might not want to take what he has to say
too seriously. I have no doubt that it's possible to find actual
fault with what I've written, but Pascal hasn't accomplished that.
Scott W. Ambler
>Scott W. Ambler wrote:
>
>8x--- Snip --
> > No, I have nothing to apologize for.
> >
>You never do, Scott, you never do! And you never will.
Actually, as Mark pointed out I apologized to the group. Thank once
again for misrepresenting me.
>8x--- Snip --
> > > never answered questions posed,
> >
> I've also ignored several of Remco's questions once it was
> > clear he wasn't conducive to the answer I was providing.
> >
> Translation: You've failed to convince remco of your viewpoint,
>cannot seem to find another example, and seem to have given up.
I'm not obligated to convince Remco of my viewpoint. I shared it
with him, put a fair bit of effort into trying to help him to
understand, and apparently he didn't like what he was hearing. Oh well.
> If even people in power cannot understand that the article is a
>joke, doesn't it drive home Ravi's point that the average software
>developer is incompetent?
No, it shows that a few people in power didn't understand that the
article was a joke.
> So was he "foolish" to do so, as you earlier
>stated, Scott? You've just proved his point! LoL. (And stating he was
>fioolish was a very polite thing to do, wasn' t it? Especially since
>that statement was personal and an opinion, not fact! Are you noting
>this, Mark?)
Once again, you're quoting me out of context.
> And I don't see any support for your position from anybody except
>other authors/contributors to the magazine. The common folk seem to
>disagree with you.
The only "common folk" in this discussion seems to be you.
Tim, do you actually have anything of value to add to the
conversation, or are you just going to complain? Frankly, you're
wasting everyone''s time.
Tim
I never knew Pythagoras, yet I can form an opinion of his
mathematical skills based on his writings and his well known theorem.
The same goes for Newton, Einstein, etc. I never knew Erdos, but I
might have an Erdos number for all one knows.
Your statement that "With all due respect to Chris Date, he doesn't
know me, has never worked with me, nor has he even chosen to engage me
in conversation." does not mean anything. You have published an article
for everybody to see and criticize. Chris Date has expressed his views
on that article. He does not have to know you to form an opinion about
your knowledge of relational theory. Your rebuttal of Chris Date's
criticism of your work by saying that since you have never met, he
should not criticize you is strange, to say the least. A thinking
audience would immediately start wondering about this, asking
themselves why the author chooses to refrain from explaining himself
but, instead, gives a non-answer.
It is precisely the fact that an authority asserts that you do not
have knowledge of database fundamentals that makes your constant
referral to your work on "agile" data modelling dangerous to the
newcomer to the field. A database novice who learns from your site will
only get an improper understanding of the field, and then propagate it.
As to why I am the only one criticizing your work, let's see. You
kicked out Ravi, refused to acknowledge remco's points (claiming
insistently that you were correct!), and are now refusing to
acknowledge the fact that when somebody who is universally considered
an authority says that you do not have enough knowledge of the field,
that it is possible that you may have a thing or two to learn about the
field. You choose to ignore that criticism by making statements to the
effect that you haven't met him!
Is this the level of discouerse you want to indulge in?
You keep claiming that I (and others) keep quoting you out of context.
The context is clear for all to see.
As for your claim that database professionals must change their
worldview and come to embrace more agile methods currently in vogue,
shouldn't they ask why they should do so? Shouldn't they ask you to
explain how it will benefit them? Or should they just blindly follow
you? Their field in based on sound mathematical principles, set theory
and predicate calculus. Has anything you have to offer invalidated
either of these fields? Then why should they follow your ideas? Have
you engaged them in open debate? or, as is apparent to me from your
writings, your belief that data professionals are bad permeates the
conversation that you have with "data dinosaurs"?
I am sure that the mathematics community is very eager to listen to you
if you say that you have something better than set theory and predicate
logic to offer! (Is this another example for you to say once again,
"I've been quoted out of context?") If not, then you have to convince
them that your method has benefits. Why should anybody accept
everything new that comes up? There was this stuff that a Curt Monash
put upo about DBMS2 without giving any specifics, should everybody
blindly accept it because it is new? How about the "Concept Oriented
Model" that Alex Savignon created? He himself claimed that he could not
explain it well enough, yet on dbforums.com was peeved that people were
not willing to listen to him and accept his theory on faith! He, too,
claimed that the group was interested in preserving the status quo, not
on learning new things! But he had nothing to add to the body of
knowledge!
What benefit does Agile bring to the database world? Will it change the
way we do data modelling? Change assumes that the normalization rules
are improved upon, something better than set theory and predicate logic
comes along, etc. We do not see that happening. Possible, but it hasn't
happened yet. So why do you keep pointing to your AgileData Modelling
articles? How exactly does it help your so-called "data dinosaurs"?
Will UML data models be any different from data models developed using
Case tools, ERWin, etc? If not, how does it benefit the database
professional to learn how to model data using UML? Just enough
knowledge to understand class models (OO models) should suffice, I
think. So why do you keep pointing to your UML data modelling
articles, among others?
As some wise person said, "Applications come and go. Data stays."
Organizations are concerned both with data and applications. But they
realize that data, once corrupted, is not easy to cleanse. Hence they
take more care about data, using the relational model to ensure the
integrity of the data by eliminating update anomalies, etc..
The fact that applications come and go should be obvious to software
professionsals. Many languages had their heyday: COBOL, Pascal, C, C++,
Smalltalk, Java, and now C#. Each has its specific strengths and
weaknesses, was/is appropriate for the time, etc.
But the data they manipulate within an organizatiuon remains the same!
Customer data collected by a bank over the years does not become
irrelevant just because you have written an application in C++ instead
of C (or Java instead of Smalltalk, etc.) Data stays for much, much
longer than applications. And that is a practical fact of life.
Tim
Tim
viewpoint. I shared it
with him, put a fair bit of effort into trying to help him to
understand, and apparently he didn't like what he was hearing. Oh
well. "
Your statement that you "helped him to understand it" carries the
undertone that your viewpoint is right, that it can never be wrong. I
would have phrased it somewhat differently, saying something like "I
tried to explain my point", not that the other party failed to
understand. No wonder if you are not very successful in convincing
"data dinosaurs" to chnage their viewpoint.
Tim
theory as database
specialists do - the question is - does that matter?. "
Generally no. But if the person keeps taunting data professionals by
referring to them as dinosaurs, then shows a complete lack of knowledge
about the things he is talking about as is easily evident to any
database programmer with a knowledge of the fundamentals, and whose
writing has been criticised by the leading authority in the field, then
he should not expect that all his pronouncements on database theory
will be welcomed by the database community. When he passes himself off
as an expert on database theory, in spite of being criticized by the
leading authorities as somebody who has no knowledge of the field, then
that is sure to inflame all database professionals worth their salt.
And do re-read your first post, Mark. This time cover the sentence
about school playground with your fingers and read it. Isn't that
enough? Why add the schoolchildren part un-necessarily? That was rude
and unnecessary.
Your first reaction seemed to be, "How dare Ravi criticize somebody as
well known as Scott Ambler?" You never bothered to read the original
article before issuing the cease and desist edict. And you should have
done the same to Scott Ambler, too. This shows that you are not
interested in being fair.
Tim
Obie Fernandez
Mark,
Please unsubscribe me from this list... the constant bickering is intolerable.
Obie