Re: Building Slow Development Systems (On Purpose)

Apparently this didn't make it on my first attempt, so I am resending it. 
====================================================================

Thanks for all the comments.
First off let me say that I haven't ever intentionally slowed down a development system and in fact until last week I hadn't even thought about it. But I do find it to be an interesting idea.
Looks like most of those that responded object to this approach. I don't really like the idea of manipulation, preferring direct communication (sometimes overly direct). However, I think that sometimes it can be very difficult to get through to some groups of developers, particularly those without strong Oracle backgrounds. By the way, I have a developer background, so I don't want anyone to think I'm bashing developers here.
This whole discussion reminded me of a saying about sales people, that the only way to really communicate with them was through their comp plans. Obviously that's an oversimplification, but actions do speak louder than words. And no matter how many conversations you have, sales guys are going to focus on what they get paid on. It's clear direction from the company as to where they should focus their efforts. 


A couple of things I really appreciated from the comments.
1. I liked the sports analogies - Cary Milsap sent me an offline email that had a couple of great examples (I hope you don't mind me sharing these Cary)
"There are lots of stories like this... Practicing with a .177 caliber air rifle makes an Olympic marksman a better shot with the .22, because the lower velocity means the bullet spends more time in the barrel, which means you have to stay still (between heartbeats) longer. Practicing with wood bats makes my boy a better hitter with his aluminum bat later. Practicing with a pancake mitt makes you a better fielder with a real glove. And on and on..."
2. Gary (from Australia I think, based on his domain) made some pretty good points on the blog post against doing this type of thing. It was clear from his posts that he has a group of knowledgeable developers (about Oracle I mean - including knowing the difference between lio's and pio's and being able to determine the ratio) which is not always the case. Nevertheless, he makes a strong argument that slowing down Oracle may encourage some really bad behavior, such as attempting to cache data in pl/sql arrays, or sucking the data into Java and doing most of the manipulation there, or doing away with Oracle altogether because it's too slow.
3. Several people made the point that if the development system was too slow, the developers would basically just give up which is a valid concern.
4. Test / QA systems were mentioned several times. I think there is certainly opportunity to improving testing by simulating heavy load conditions on various components, but that was not what I was thinking about with the original post. Some interesting ideas popped up here as well though. 


A couple of final thoughts on my part:
I think this approach may actually prove beneficial given the right set of circumstances. (I'm not going to run right out and change up any development systems tomorrow, but I will give more thought to the next one I encounter.) Most development systems are slower than the production systems they support anyway - primarily for cost reasons. But I think this is rarely done in a deliberate fashion. Usually it is just a function of using older or less expensive equipment. So in that regard, making conscious decisions (such as to reduced the buffer cache) may make sense. 

Anyway, I've enjoyed reading all the responses. Thanks for playing.


Kerry Osborne
Enkitec
blog: kerryosborne.oracle-guy.com

Other related posts: