Database Development Standards, Part 0 – Principle

I’ve been thinking lately about what topics to post on — and while I’m attracted to the religious arguments about developer DBAs and DBA developers and who develops the SQL and who designs the tables and who writes the PL/SQL and whether or not you should use stored procedures… (deep breath)… I think we’ve all heard variations of that song ad nauseum. :-)

So, given that, I think I’d like to talk about the development process itself.

I’m going to try an describe a possible process for developing an internal applications with reasonably high uptime requirements and fairly frequent feature introduction and/or bug fixing.

I’m NOT going to focus on coding and naming standards.  Honestly, I don’t care too much about those — only that they are consistent.  And heck, anybody who specifies spacing and alignment needs to chill out and look into pretty-printers and code formatters.

This will be a multi-part series and I’d love to hear feedback — even specific questions and scenarios.

BTW, the reason I find this topic interesting has to do with some of my notions around the construction and formation of development teams.  In general, I believe that as a manager my job is to remove as many non-coding obstacles as possible from my staff in order to allow them to be as productive as possible.  (I read a fair amount of Mills and Yourdon a long time ago — I know, today I’m supposed to speak about “agile” development and “extreme programming”, but sometimes I just like to avoid the tags and speak about the underlying methods and results).

I’ll close this post with a guiding principle: A development process should promote efficiency — not add overhead or administrivia.

Leave a Reply

Posting code can be a pain. To make sure your code doesn't get eaten, you may want to pre-format it first by using HTML Encoder