Collection interfaces

[Topmind]

>
> Before you knock
> it, TRY it -- pick a pilot project of suitable size, a team
> ditto, and have a go at it with eXtreme Programming

Sure, hack-it-til-it-works indeed does work after enough
time. But whether it produces a better system in the
long run is another issue. Without better metrics, it is
just Yet Another Methodology to add to the heap.

How about you try heavy table-oriented programming for a 
few years.

> code test-first, *refactor mercilessly*,

I would rather use task-orientation and avoid
excessive refactoring to begin with.

"Refactoring" is a euphemism for "OO is not
change-friendly after all".

>
> This seems to show what blind alleys classical approaches can
> lead one to -- ```Reorganization can be risky. Many managers do
> not want programs altered except to add or fix features. If an
> significant error occurs due to reorganization, then heads roll.
> I have been told many times, "If it ain't broke, please don't
> fix it."''' being the key quote from that paper.

Well, they are the boss. Sell rework to them, not me.

> (But the ills are many indeed; the
> "lava flow" anti-pattern, for example, is likely to be quite
> pervasive in a development shops to which this article could
> apply).

What is this "lava flow" thing? I keep hearing it mentioned. 
More OO lore that nobody can keep up with. Scriptures 
build fast when the agnostics are silenced.

I have shown in great detail why procedural seems better able 
to deal with non-boundaried differences, and I have yet to
see counter-arguments other than "you get used to code
rework if you just give it a fancy name." 
I won't sell out to wasteful effort.


> But the right unit of encapsulation is NOT the method, nor
> the object, nor the class; it's a *component*, a small to
> middling set of classes/objects/methods (and, in languages
> which allow other organizing structures, functions, modules,
> etc), which are developed and tested and released _and, thus,
> reused_ *together*.  Component boundaries are indeed of very
> high relevance.  Boundaries _within_ a components are not.

But the easy-to-componentize stuff is already for sale. Why 
would they bring in programmers if plug-and-play solutions
were already available? (Report writers, sorters, DB's,
GUI IDE's, communications, etc.)

What is left is stuff that has a jillion interconnections
to other things such that putting a clean box around it
is not practical. Components usually work for things where
the algorithm is complex but the interfaces are small.
In biz stuff the interfaces/links to many entities is the
largest part.

Besides, you can characterize my development philosophy
as "task componentization". AKA, a procedural module.


> Adopting the 'software that happens to appear to work when
> not thoroughly tested is sacred and must not be touched' idea
> is parallel to keeping a kid always on his/her side of the
> street (except perhaps for emergencies such as schools and
> doctors:-).  Not exactly conducive to optimal development
> (be it of social skill and a healthy life, OR good software).

I am not against re-arrangement. What I am complaining about
is paradigms that *increase* the amount of re-arrangement that
is required. OO appears to do such, partly because of the 
boundary/granularity issues.

The whole refactoring thing is side-effect of OO. The paradigm
is starting to barf, and now the same people who sold you
the barfers are now also selling barf bags.

Whadda Racket!

If I was not so merit-minded, I would probably happily
cash in on it too. 

-tmind-