When talking about just the development space (i.e. excluding apps and OS requirements), it really depends on the type of project(s) you are dealing with. For example, compiled languages create a lot of temporary files that are in turn repackaged into larger files. In my current environment, we are currently running about 20GB for the source code + the compiled object files. That's only including the DEBUG compiled version, it would be more for RELEASE compiled as well.
Please don't forget the 20% overhead that NTFS or other journaling file system (assuming Windows here) needs to have room for journaling and keeping the hard drive healthy. You'll have to size the hard drive needs yourself.
When projecting the hard disk needs of your project, you'll have to consider the following aspects:
- What assets are final products? Items in this class include art assets, images, sound files, etc. that aren't combined into another file. In a web application this includes your CSS and JavaScript files as well. Don't forget your build scripts and other items that are not compiled.
- What assets generate intermediate results? Items in this class include source code for compiled languages, link files, etc. At the beginning of the project, you'll have to project how big you expect these to get, and revise those estimates at least twice more as the project goes on.
- How big are the final products? Your DLLs or shared libraries also take up space. Same as if you packaged your web application into an easily deployable unit (similar to a Java WAR file or EAR file).
For a rough estimate of how big your final estimate is, use the following formula:
(2 * _static_) + (2 * _intermediate_) + (2 * _final_) * 1.2
If you are thinking to yourself, how can that be? Consider the following:
- The compilation process copies static files to the build directory, as well as the compiled classes.
- The linking and packaging stage will create final binaries that will be smaller than the combined intermediate files and static files in the build directory, but doesn't erase those files as they are combined.
- The final product is only marginally smaller as binaries can't compress very well--but you can remove redundancy.
- You need to account for temp space to allow the compiler to work. This is what the extra space allocated in the final product is for.
- Lastly, you need to make sure the dev environment has some breathing room so the OS can keep the drive happy. That's what the 20% increase at the end is for.
If you are at the start of a project, have your developers provide a SWAG (Seriously Wild A** Guess) as to how many classes would be needed to implement the feature. Multiply that by 16KB. Some classes will generate much smaller object files, and others will generate larger ones. But this should be sufficient for your SWAG estimate of disk space. Also assume your final products will be the same size as the classes you estimated.
I assume your employer is wanting to set up quotas for each user profile. I sincerely hope they are not entertaining roaming profiles with the dev environment. The problem with roaming profiles is the shear volume of files that need to be transferred. Windows OS (and the Samba protocol) are notoriously inefficient at transferring large numbers of files. It will take an order of magnitude longer to transfer 100 1k files than 1 100k file.
Hopefully this gives you enough information to negotiate with your employer.