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.