Needs to know everything; was: RE: [AM] ZZZ

(responding to Dagna)

> EVERYONE NEEDS TO KNOW EVERYTHING!

>> Anyway, the basic problem from my point of view is that
>> I'm not sure I understand.  I may be good at 'agility' but I
>> am not a DBA.

> DG: Unless you need to know how the DBMS works, you don't
> need to spend too much time discovering the fine details
> (although a general understanding is essential, IMHO).

Actually I helped develop 2 DBMS - doesn't mean I know how 
to use the things, though  ;-)

> That's what the DBAs are paid for - and part of their job
> should be helping people who don't need to know the details,
> work stuff out that they need to do.

Are you *sure* you work with data?  Or were you just about
to add the "but not until 6 weeks after they ask for help"?  ;-)

> I firmly believe that what we all need is the ability to understand
> the other person's concerns and viewpoint.

Definitely.  That's my take on the "Generalising Specialist"
idea - you should know enough about the work of anyone
you're communicating with to understand what they are
saying - ideally you should be able to *do* the basic 
elements of their work.

> Even if we don't agree with it (it makes arguing and persuading
> much easier). Next time a DBA has a hissy fit and refuses point
> blank to even consider doing x - ask them why, and explain
> that if you understand the reasons it will make both your
> lives much easier in future. And when they have explained, you
> can maybe rephrase your request or redo it in a way that won't
> bring western civilisation down by the end of the day. (As the
> aforementioned DBA explained would be the inevitable
> consequence of your new column.)

I think what may fall through the cracks here are the cases where 
the DBA gives explanations that are valid in the good old
fashioned traditional environment, but no longer hold true in
the agile world.  I guess if the DBA doesn't know how to do it
in an agile fashion we are stymied anyway - but the ability to
say there's another way *would* be handy.  The DBA might
just consider learning how to do it the agile way.

> And, sometimes, someone is horribly overworked, incompetent,
> in a bad mood, lazy, or just hates you. 

What, after all the new schema and migration script stuff I
gave him to help him with the changes we need?  How could
that be?  We nearly did his work for him!   :-)


>> My thoughts are that if everyone went through stored
>> procedures, then you'd only have them as clients of the 
>> database.  I guess the picture isn't so simple for some 
>> reason, but why not?
>
> DG: If every new development uses stored procedures, then
> life will get easier.

So, are they?  I saw embedded SQL being written only last
year, and I expect to see (and moan about) more for a few
years yet.

> And, eventually, all the old apps will get replaced (the tape
> drives will get too expensive to maintain, the people who write
> assembler will come up to retirement and no-one will want to
> take a job using it, the companies will get taken over and the
> either the take overer or the take overee will have a spiffy new
> system and there will be a corporate will to move from a
> dozen billing systems to only two or three, and then the old data
> will get migrated or dumped. And there will be world peace. <g>)

Hmm... let me paraphrase... The old apps will get replaced by
carbon copies but in procedural Java not Cobol or assembler;
Somebody will build a next-generation tape drive because
there are too many systems needing the hardware; The assembler
programmers will retire before the programs are replaced, and
nobody knows what they do, so we need to build an assembler
emulator so they keep on working when the mainframe goes;
the companies will choose the worst of the systems because the
modern systems are easy to replace but the bad ones are too
hard to replace; the old data will get older and dirtier, but that's
all we've got...  cynical, me?

> And one day, an old hack will be someone who remembers
> Java. (Currently, an 'old hack' is likely to be someone who
> remembers paper tape, punch cards, and that you could play
> Smoke on the Water on mainframe core memory.)

I never played  Smoke on the Water on mainframe core memory,
you must be thinking of somebody else.  Pete?   The beads
hurt my teeth.  Was I doing it wrong?


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------