Feature (bloat), orthogonality
Bernard
software products on the market.
New features and feature bloat is not a new phenomenon.
My question is: new features being part of the game and the customer
funding it through maintenance fees, what can this customer expect.
Quality (performance and stability) and orthogonality.
My observation is that the core capabilities of software products
improve in quality, most of the basics being part of the product for a
long time.That the new features, after a while tend to reach the
quality of the old one.
But orthogonality, is it (still) there? Meaning, being able to combine
features as the user wants it.
The answer is, no. It is not 100%, which is: not enough.
So once again, kindly asking that when new features are introduced,
orthogonality is just broken for one release, the next one restoring
it for the capabilities added in the previous one. The customer
through it's maintenance fee
is part of the development funding. And part of the maintenance money
that unnecessarily is going to support (calls being result of lack of
orthogonality) can also be used for it.
Bernard Dhooghe
Serge Rielau
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
Mark A
news:8n5adg...@mid.individual.net...
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).
Bernard
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
Mark A
news:bc318bb4-b1d3-4bd0...@m37g2000vbn.googlegroups.com...
> 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...).
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.
Bernard
> "Bernard" <dhoog...@yahoo.com> wrote in message
Maybe I should have written:
'
One release, ok. If not, drop the capability ( or DPF :) ).
'
Bernard
Mark A
> Maybe I should have written:
> '
> One release, ok. If not, drop the capability ( or DPF :) ).
> '
> Bernard
It is not necessary that every DB2 feature be supported by DPF (HADR for
example), but again, they are not going to "drop" DPF.
Will Honea
> Note that the devil is always, always always in the edge-case that comes
> with orthogonality.
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