All right I bite, with the disclaimer that this is my personal opinion.

If you see a feature a s a dimension, then with every feature that you
add a dimension is being added.
The more dimension you add the more complex the product gets and thus
the more complex to fully test and implement a feature gets.

There are some limiting factors. For example an SQL features by
definition be orthogonal to. e.g. backup/restore.
But painting with a broad brush it is clear that supporting the
combination of everything with everything is very expensive.

Now, with those maintenance fees which you rightly or wrongly see as an
investment into future features (that could be another debate I take it)
shouldn't a company spend them wisely?
And wisely means to look at what is being used, or what it expects usage
to be and then implement that?

Note that the devil is always, always always in the edge-case that comes
with orthogonality.

Let me give you a very hands on example.
Right now I'm working to add a new aggregate function to DB2.
It is special in the sense that it uses two arguments.
First approach was to go for maximal orthogonality of these arguments.
Everything worked fine with my implementation until I started with DPF.
Oops, suddenly that second argument caused me trouble and I was stuck
between either doubling my implementation costs or place some very
reasonable (as in I can for the life of me not come up with a good
example why orthogonality is needed) restriction.
I do not think that I can, in good faith drain my teams resources (and
our customers maintenance fees) for the sake an an edge case.

Anyway as a developer and language architect I see both sides of this
and pragmatism has a lot of sway in real life.
(luckily)

Cheers
Serge

--
Serge Rielau
SQL Architect DB2 for LUW, IBM Toronto Lab
Blog: tinyurl.com/SQLTips4DB2
Wiki: tinyurl.com/Oracle2DB2Wiki
Twitter: srielau

"Serge Rielau" <srielau (AT) ca (DOT) ibm.com> wrote

My personal opinion is that a lot of features seem to get added to impress
executives, managers, and idiot DBA's when making a DBMS buying decision,
and that "tends" to make the product more complex and/or more unreliable and
slower.

IBM is also having to pay big time for mistakes made in the 1990's when the
LUW product was first developed (not very well) and when they lost
significant market share to Oracle, and has to implement such features as
Oracle compatibility (Oracle does not have to worry about DB2
compatibility).

On Dec 19, 3:53*am, Serge Rielau <srie... (AT) ca (DOT) ibm.com> wrote:
With more dimensions and orthogonality-at-best, the product is not
only difficult to test (quality dimension), such new capabilities will
only find a small numbers of users, (too) difficult to fit in in the
existing framework.

An approach is just to drop what is not orthogonal, or as I propose
just have orthogonality leakage the time of one release. To comment
back on the example given, if a developer uses the new capability, it
can not be deployed in DPF. For how long? One release, ok. If not,
drop the capability (or DPF...).

All the best for 2011,

Bernard

"Bernard" <dhoogheb (AT) yahoo (DOT) com> wrote

I don't know the situation in question, but DPF is key technology for IBM
and an integral part of DB2. It generates huge amounts of revenue for IBM,
so the idea of dropping DPF is totally absurd.

On 19 dec, 23:14, "Mark A" <no... (AT) nowhere (DOT) com> wrote:
Maybe I should have written:

'
One release, ok. If not, drop the capability ( or DPF ).
'

Bernard

"Bernard" <dhoogheb (AT) yahoo (DOT) com> wrote

It is not necessary that every DB2 feature be supported by DPF (HADR for
example), but again, they are not going to "drop" DPF.

Serge Rielau wrote:

Even more difficult is the corner-case defined by the intersection of two
edges. These one-in-a-million intersections rapidly exceed one's ability to
identify, much predict, so testing either becomes over-riding cost factor or
is ignored.

None of the Comp Sci courses I either took or taught have included a decent
presentation of the economic analysis required by good design. Those
decisions are too often left to the bean counters and remote managers.

--
Will Honea