September 23, 2001 at 8:37 pm
I've noticed a number of interesting posts on this site about what rights DBA's and Coders should have on Production and Dev environments, and also articles on VCS's and keeping things under control. My question is along these lines, but it's about how to help DB Coders learn the design of the DB so they can write Stored Procedures correctly and quickly.
I am A Database Designer that hates Coding, I have a team of Coders working to produce the Stored Procedures etc required for the Database I'm working on.
I have to communicate to the Coders exactly what I require from them in order for our ASP site to work.
It is a VERY complex database and has a HIGH learning curve.
I'm not being very successful with communicating what I want the SP's to do.
My current way of describing is something like this
SP Name: procSampleSP
Parameters: @Sample_ID, @SampleDate, @SampleDesc
Create new Record in tblParent using the Description and Date parameters
Copy the contents of tblChild where the Parent_ID = @Sample_ID to the newly created tblParent record's ID
Return the new ID of the tblParent
As a bit of background, our DB is a very industry specific DB and has lot's of terminology and concepts that the coders just don't understand - I'm sure there are other industries out there that have similar problems eg Medical, Legal etc.
Is there a standard way of defining this pseudo code so that it can be understood by the coders? or how can I improve on this example without writing so much that I could have written the SP myself? I would be interested in knowing what strategies other organisations use to handle this dilema.
Thanks
Jodie Miners
September 24, 2001 at 4:48 am
For the example you cited, Im not sure what would be better. In what way are they getting it wrong? Without knowing that, my first though is that you're mired in detail - as a designer/architect, as long as the proc accepts the parameters and provides the required result - it should be a black box, doesn't really matter a whole lot how they accomplish it. I would think coding standards and style would be someone elses responsibility.
Curious to see how they are going wrong!
Andy
September 24, 2001 at 11:14 am
i think the issue here is not explaining what the SP does but what the system or the module does as a whole .. unless the developer has a good knowledge of what the system or the module is expected to do it is going to be very difficult to achieve this .i can understand the frustation as i've just redone the coding on most of the procedures that i had myself assigned to some developers .. but i'm going to try to avoid this by explaining the modules in much more detail to the coders next time .. any other way , in my opinion would be a waste of time..
September 24, 2001 at 10:41 pm
Thanks, GRN for your thoughts, I think that is the answer, and I'm just about to try that again now with some spec's I'd previously written in the same manner, but a new piece of work, so hopefully if I explain the outcomes they should be able to get it right.
Andy, on the subject of what did they get wrong - everything. The problem is that two different people looked at my spec and got it wrong 4 times and spent a number of hours on it before I just re-coded it myself (in 5 minutes).
I will try and report back my progress with the next SP's that are written,
Jodie Miners
October 4, 2001 at 5:33 pm
Jodie,
How experienced are your coders in SQL Server? How quickly do you follow up on assignments? We have a 30 minute rule - if you are still working on the same thing after 30 minutes grab someone else and see if both of you can solve the problem.
Another idea from my project manager days is to have the coder repeat your instructions back to you to be sure they understand them. That would also give you a better understanding of what information they need.
Patrick
quote:
Thanks, GRN for your thoughts, I think that is the answer, and I'm just about to try that again now with some spec's I'd previously written in the same manner, but a new piece of work, so hopefully if I explain the outcomes they should be able to get it right.Andy, on the subject of what did they get wrong - everything. The problem is that two different people looked at my spec and got it wrong 4 times and spent a number of hours on it before I just re-coded it myself (in 5 minutes).
I will try and report back my progress with the next SP's that are written,
Jodie Miners
Quand on parle du loup, on en voit la queue
October 4, 2001 at 5:56 pm
Hi Jodie - missed your last reply or would have posted sooner.
I like Patrick's idea of the 30 minute rule - you want them to wrestle with it and learn, but not waste tons of time. I think this goes back to design - not only have them repeat it back to you, but better yet, have them "design" it and them explain the design to you. Is it overkill to design a stored proc? Maybe. But you teach them good habits on a small scale. Having them explain their solution before they code it - you have the chance to explore other alternatives, basically turn it into a coaching session.
I still think your spec was relatively clear. Any more would be to write it yourself. If you can write it in 5 minutes, it doesnt make sense to spend more time than that to write the spec. It would seem that in this case anyway, its more a case of the skill level of the coders than your skill writing the spec. Either have to train them or find new ones, right?
One thing that might help is to really standardize your spec syntax (and what you have seems good to me) so that they are "used to" finding bits of info in the same place each time. Maybe a code standard document that shows the spec coupled with the "correct" answer in code. You might also benefit from trying to treat your specs as different design patterns -- the copy record pattern, the update pattern, the audit pattern.
The only other option I can see is to buy/build a code generator, so that you can run the wizard and answer the questions, generate the code. Pretty effective for standard insert/update etc operations.
Andy
October 4, 2001 at 7:39 pm
Thanks Andy, that is some very good sound advice.
I tried things differently this week and we had a meeting between all parties involved in the next piece of work. I still got caught on my language though, I used the some words in their regular meaning and they were confused with fields in the database, so the idea of spec syntax templates is a good one. (when I say X, I mean do A, B and C). We are also working on improving our Database diagrams and help for the coders. Hopefully we will get better each time.
Thanks for your help.
Jodie Miners
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply