Paul Oldfield
2004-02-04 22:17:36 UTC
(responding to Dagna)
to use the things, though ;-)
to add the "but not until 6 weeks after they ask for help"? ;-)
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.
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.
gave him to help him with the changes we need? How could
that be? We nearly did his work for him! :-)
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.
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?
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: gcma-***@gmane.org
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com
TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------
EVERYONE NEEDS TO KNOW EVERYTHING!
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 howAnyway, 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'tI'm not sure I understand. I may be good at 'agility' but I
am not a DBA.
need to spend too much time discovering the fine details
(although a general understanding is essential, IMHO).
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 aboutshould be helping people who don't need to know the details,
work stuff out that they need to do.
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"the other person's concerns and viewpoint.
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 wheremuch 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.)
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 Iin a bad mood, lazy, or just hates you.
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, thenprocedures, 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?
life will get easier.
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 bydrives 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>)
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,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.)
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: gcma-***@gmane.org
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com
TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------