Message-Id: <10501.105995@fatcity.com> From: Bruce Page Date: Thu, 18 May 2000 12:40:21 -0500 Subject: RE: Re[2]: Oracle DBA opening in Englewood, CO This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFC0F0.383299AC Content-Type: text/plain; charset="iso-8859-1" I had an end user one time give me very sketchy requirements. I went bad to her to flesh them out. She said I should have enough to get started. At the time she was in the process of building a house. I asked her how the house was coming along. After her talking for a few minutes, she got to a part where she had changed her mind about something, but it was too late in the building process to change (without adding a lot of rework cost) so she had to live with it. I jumped at this. I pointed out that "requested changes made too late" was what I was trying to avoid. I explained to her that building a house (I grew up doing construction work) is not much different than building a system. Once things are done, they are done and for them to change requires a lot of rework and delays. I never had a problem with her again. If you can explain to them in a manner they understand, the users are the best source to get system requirements from. -----Original Message----- From: dgoulet@vicr.com [mailto:dgoulet@vicr.com] Sent: Thursday, May 18, 2000 11:26 AM To: Multiple recipients of list ORACLE-L Subject: Re[2]: Oracle DBA opening in Englewood, CO Well, I can't speak for all developers, but the ones we have are pretty smart and they write some really good scripts (for the most part). And our management requires that we test them out in a development area before running them on production, so none of the previous bothers me. Where I have a problem is the end user community that drives the developers. There has been more than a dozen cases where what the end user wanted was not what the developer delivered because the end user was not sure what he/she wanted. In my book there is no substitute to good requirements definition and a clear understanding of those requirements by both parties before the first line of code is written. ------_=_NextPart_001_01BFC0F0.383299AC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Re[2]: Oracle DBA opening in Englewood, CO

I had an end user one time give me very sketchy = requirements.  I went bad to her to flesh them out.  She said = I should have enough to get started.  At the time she was in the = process of building a house.  I asked her how the house was coming = along.  After her talking for a few minutes, she got to a part = where she had changed her mind about something, but it was too late in = the building process to change (without adding a lot of rework cost) so = she had to live with it.  I jumped at this.  I pointed out = that "requested changes made too late" was what I was trying = to avoid.  I explained to her that building a house (I grew up = doing construction work) is not much different than building a = system.  Once things are done, they are done and for them to = change requires a lot of rework and delays.  I never had a problem = with her again.

If you can explain to them in a manner they = understand, the users are the best source to get system requirements = from.


-----Original Message-----
From: dgoulet@vicr.com [mailto:dgoulet@vicr.com]
Sent: Thursday, May 18, 2000 11:26 AM
To: Multiple recipients of list ORACLE-L
Subject: Re[2]: Oracle DBA opening in Englewood, = CO


Well, I can't speak for all developers, but the ones = we have are pretty smart
and they write some really good scripts (for the = most part).  And our management
requires that we test them out in a development area = before running them on
production, so none of the previous bothers = me.  Where I have a problem is the
end user community that drives the developers.  = There has been more than a dozen
cases where what the end user wanted was not what = the developer delivered
because the end user was not sure what he/she = wanted.  In my book there is no
substitute to good requirements definition and a = clear understanding of those
requirements by both parties before the first line =