dynamic naming for hierarchical problem

[Alex Martelli]

"Peter Hansen" <peter at engcorp.com> wrote in message
news:3B75F8E0.10178322 at engcorp.com...
    ...
> > 3)  (And this one is primarily for Peter Hansen, to answer his statement
on
> > picking something simple and getting it working)
>
> To be fair, Alex was the one who first brought that up in this
> thread and I was really just echoing my agreement with his
> Pythonic reminder about simplicity.  :)

To be fair in my turn, Guido was the one who first brought
simplicity to Python and I was really just echoing my agreement
with his Pythonic design of simplicity.  :)


> > quickly.  And I would probably (as Peter pointed out) be following good
XP
> > rationality by doing so.  However, I think that XML fits in nicely for a
> > future project that I have in mind.  I know that this violates XP, but I
> > have that flexibility with the project that I am working on right now.
So,
> > for my technological growth and for learning something for a future
project,
> > I will probably go with XML.
>
> All the reasons you mention are excellent reasons to go with
> an approach which might not give you a working solution "right away".

Yes -- as long as you're not robbing Peter to pay Paul, which I'm pretty
sure from the original poster's context is not the case, but, I think, it
a valid ethical consideration in general -- so, in the following, I'm using
"you" in the totally-generic sense of "you, hypothetical reader", *NOT*
meaning specifically either Peter nor the original poster.

To clarify: if you're working for yourself or for a long-term employer,
it's FINE to "take time off" to explore technological alternatives, even
if you feel they're probably inappropriate to the current project, just
because they may come in handy in future ones.

But if you're a freelance developer/contractor, and you're billing a
customer for this project, I think it's unfair to bill the time and other
expenses for technology-exploration UNLESS your professional
evaluation is that it IS quite important to explore that specific
technology for THIS one project, in the direct interest of THIS one
customer.  In uncertain cases, I would suggest to *ASK* your
customer, the one who's footing the bills: "I think I can kludge you
up something today that would work with antiquated technology,
but if you're willing I can explore bright new technology X -- it may
or may not turn out to be the right solution, and I won't know until
I've expended amount Y of time/money exploring it in the context
of your project -- if it does fit, it will give you advantages A, B and
C".  Customers are not always as short-sighted as we technerds
may think -- let the customer make the business-decisions (can he
afford the time/money to explore a potentially better technology)
as long as you possibly can (i.e. any time there's no absolute
technological stumbling block).

Yeah, yeah, I know -- hopelessly outdated attitude; why not bill
everything and anything one may possibly bill?  Still, I believe, VERY
much in accordance with XP's philosophy, as well as with the golden
rule (isn't this how YOU would wish to be treated when YOU are the
customer for some professional in another field?-).


> XP is not about doing tiny and in-the-long-term-wasteful baby steps
> towards a distant goal.  It's a more pragmatic approach to things.

Yep.  AVOIDING waste is a big part of it.

> XP might flip things around for you: pretend that your short-term
> task is to get a quick foundation in XML, and getting a working
> solution to your test data problem is "free".

I don't see this as XP-ish, though.  Rather, the issue becomes
"let's fix the user-stories" -- somebody's first gotta write the
*tests* this piece of software must pass to be validated as
"working and meeting the specs".


Alex