Having great developers means creating a great environment. In an increasingly competitive world, that means everything from free food to paid screw-off time. But not everyone has gotten the message.
Some places still practice developer abuse. Here are its many forms. Do not indulge in more than one or two, or you may never see your best developers again.
[ 10 steps to becoming the developer everyone wants | Learn how to work smarter, not harder with InfoWorld's roundup of all the tips and trends programmers need to know in the Developers' Survival Guide. Download the PDF today! | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]
1. Hellish security
I've been to a place whose McAfee proxy bans Zip files with HelloWorld.java. This means that everything from downloading build tools to examples is prohibited. At another shop, the McAfee desfktop security scans every file a process touches for malicious code, even files unchanged since the last time it checked them in a single-threaded fashion, which means putting the entire contents of thousands of files through one core of the CPU for every operation. It took 30 minutes to launch the IDE and up to another 10 minutes to launch a build, even if the build touched only three source files and ran for a few seconds.
2. Torture tools
There is Subversion, and there is Git. Frankly, all other version control/configuration management tools are way too slow and/or painful. ClearCase is the mother of all developer torture tools. One ... day ... the ... code ... will ... check ... out ...
3. Maintenance teams
Some places still have fixed teams, which get all the sucky work. Seriously, no one will stay on the "maintenance team" once they find a better job -- and the odds are on their side.
4. Forced Windows
Forcing your developers to use Windows as a development environment if they aren't writing .Net code is pretty sadistic. Forced Windows means feeding your developers the same crap nontechnical users are forced to run, with many of the same restrictions. (I realize that someone on my team will say I forced them to use Linux. That's really too bad.)
5. Locking out all libraries
Years ago, when I worked at IBM, I was told not to use third-party libraries -- open source or not -- unless it would save me at least two months of development time because the hour or two of lawyer time necessary to vet everything would cost more than two months of my time. I upped my hourly billing rate soon after. Sure, you need a policy stipulating where and how you will consume libraries without going through a formal vetting process, but even so, "optimistic locking" is usually fine. Otherwise you're committing a heinous act of developer abuse by forcing everyone to reinvent the wheel.