Re: Deadly sins againts database performance/scalability

jeff_at_work.com (Jeff) wrote in message news:<bqi4so$29h$1_at_cronkite.cc.uga.edu>...
> In article <91884734.0312011531.262b8eeb_at_posting.google.com>, joel-garry_at_home.com (Joel Garry) wrote:
>
> >So what do you do if they are dumb-asses before they've been treated?
> >:-)
>
> Re-examine your hiring and/or compensation practices. In other words, avoid
> hiring dumb-asses in the first place. ;-)

Guess you've never been a contractor in a gummint shop ;-)

>
>
> >Seriously, some of the worst I've seen are newbies with a chip on
> >their shoulder. They come at it with the attitude that the way they
>
> Newbies or wet-behind-the-ears young'uns fresh out of college that just need
> to shut up and mature a bit? :-)

Both. Some of the worst have been customers hiring developers out of vendors. So they are new to the shop, have the ability to walk on water as far as the customer is concerned, and have a lot of experience at the vendor - which would be one of the same vendors that do some of the worst deadly sins, often in the name of database heterogeneity. And since they can walk on water, they can poke data and code into the production db... right?

>
>
> >Personally, I'd rather that developers be encouraged to be creative,
> >with a filtering process that explicates Oracle's issues with
> >attempted solutions (in a practical sense that means Explain Plan and
> >code reviews, as Daniel points out). This tends to be at odds with
> >classical formal design processes.
>
> What're "classical formal design processes?" Because I think code reviews
> with an experienced DBA that provides developers with insight in how to do
> things better should be welcomed... as long as the DBA isn't full of shatt (or
> himself) and/or an ass about it. I think experienced developers would, at
> least.

By that I mean doing all design work and pseuodocode (or whatever the particular process favors) up front, and the developers just grind code. The diametric opposite is Rapid Application Development (RAD, or similar buzzwords like Extreme Programming). Personally I prefer a middle ground with a bias toward RAD, with care given to watch for the downsides of each. To me, the power to have excellent development lies in the feedback of an iterative cycle. The top-down approach coupled with deadlines tends to give code reviews short shrift. Total RAD can wind up with an unmaintainable mess, especially when customers can too easily modify vendor code.

Not that I'm complaining about any of this, it means full employment for me. I'm just repelled and fascinated by the horror stories.

jg

--
@home.com is bogus.
http://www.signonsandiego.com/news/uniontrib/tue/business/news_1b2peregrine.html