I couldn't agree more with what pando (and some not_enough_well_known_whitepapers) say about fragmentation and extent sizing.

This fragmentation question is an old and ever-lasting topic among DBA comunity, yet still so many DBAs spend so much energy and time (and money) in defragmenting their tablespaces and belivs in mith that "fewer extents is better for performance, the above limit for number of extents should be 5/10/20....".

I also like the way how marist89 catches his developers when they sneak some segments into production database. I've heard even better and nasties one. Suppose your largest datafile in a tablespace is 500M. Set the default tablespace storage parameters so that INITIAL and NEXT are larger than this, say 600M. That way developer will not be able to create segment in a tablespace unless he set the storage parameters at segment level which forces him to think about this stuff and maybe even let his DBA to explain how storage parameters work and why are they used ;-)).