DBA or Development? Chicken or Egg?

[ASF]

General question here.

You've been asked to develop an inhouse corporate app that is
data-centric. Lots of editing, inserting, searching, and researching.
How does your workflow and division of labor work? IOW, do you have a
separate DBA who sits in with the client, sees how they do their work
currently, builds a pretty relational back-end, AND THEN you start
developing the app, using the DBA as the subject matter expert and the
"go-to-person" for info on requirements?

Or are you the one who sits in with the client, gets their
requirements, etc...

I am in a situation similar to the first scenario above and it's just
beginning to get frustrating to constantly be forced to adher to a
pre-built and relatively inflexible back-end. Then when it gets demo'd,

I'm constantly forced to rework the app to adher to the back-end
"requirements" AND the clients "requirements."


Am I just being silly or is this a valid complaint?

 

[SRussell]

General question here.

You've been asked to develop an inhouse corporate app that is
data-centric. Lots of editing, inserting, searching, and researching.
How does your workflow and division of labor work? IOW, do you have a
separate DBA who sits in with the client, sees how they do their work
currently, builds a pretty relational back-end, AND THEN you start
developing the app, using the DBA as the subject matter expert and the
"go-to-person" for info on requirements?

Or are you the one who sits in with the client, gets their
requirements, etc...

I am in a situation similar to the first scenario above and it's just
beginning to get frustrating to constantly be forced to adher to a
pre-built and relatively inflexible back-end. Then when it gets demo'd,

I'm constantly forced to rework the app to adher to the back-end
"requirements" AND the clients "requirements."


Am I just being silly or is this a valid complaint?

Data always comes last. The client doesn't know or give a rats ass in
general. They only want a report, or ????

So you get your requirements as to what the thing is supposed to do. You go
over it a few times. You define what the business rules are all about. You
get the flow straight.

Now you can talk to your dba on what your doing. Now they will be helpful,
and the two of you will be able to really get it right.

 

[Karl Seguin [MVP]]

I generally agree..Though in a small team (sounds like you only have 2
people), the most senior person tends to automatically fall into the lead of
"architect".

The other big factor is how technical the client is. If they are used to
using advanced reporting tools or messing directly with the database (say an
Access extract), it'd be hard/pointless to pull them away from that world.

Karl

 

[sloan]

As I mature as a developer, I sit down after getting the requirements, and I
develop a ER diagram w/ the dba.

http://www.infocom.cqu.edu.au/Courses/spr2000/95169/Extra_Examples/ERD.htm