16 ways to torture developers

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.

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.

6. WebSphere

Look, I can live with DB2 now that IBM finally added READ_COMMITTED. But WebSphere is too painful. Don't make me boot WebSphere or go through the 50 GUI screens necessary to deploy a WAR file. Seriously, WebSphere is developer abuse pure and simple. It is bad. It has always been bad. If you take nothing else away from this, uninstall WebSphere. Otherwise, your developers will hate on you behind your back. If they don't, you need better developers.

7. Marching unto death

If you force your developers into a constant death march, you burn them out. Also, they feel like they've put everything together with paperclips and duct tape. A maintenance sprint is not the answer because no one wants to clean up a big mess for weeks on end. Instead, give your developers slightly less time than they want. Anything more will produce cost overruns, and anything less is developer abuse.

8. Ah, 2010 was a good year

So you really like "standardizing" on old stuff -- say, a three- to four-year-old version of an IDE running on a version of the operating system (probably Windows) it wasn't ever tested on. In a competitive labor market, you can bet someone will offer them full benefits and the chance to use a newer version.

9. I'm sorry, we only do boring

I sympathize that you hate HipsterHacker architecture. You don't want a system that was developed entirely in "oh look shiny let me download that too." On the other hand, making your developers write code in the same set of stuff with nothing new under the sun makes them think about their career. Mix it up, let your developers touch new stuff, and mitigate the risk into a stable architecture.

10. The VM of the eternal hourglass

Your company is totally virtual! Even the development environments are virtual! Cool beans, man! Oh, but you underfunded the hardware or didn't tune it right, so everything is slow, horrible torture. Some people are Zen and don't mind a two-hour-long build process. I am not one of those people.

11. The faux-scrum daily standup meeting

There's a special level of hell reserved for the worst sinners. It's known as the daily scrum meeting for management status updates, where everyone feels compelled to talk for at least five to six minutes, not to convey important developments, but to communicate to management that they're busy doing stuff and should stay employed. The meetings inevitably have 12 or more people in them, the vast majority of whom don't need to be present. They run for 30 to 45 minutes or more (a real scrum should take about five to six minutes), and everyone not speaking spaces out. Worse, no one does any work before these meetings because they know the context switch is coming. After the meeting, well, lunch is in another hour anyway, so why start anything hard now? Basically these meetings cost your team their entire morning, poison morale, and accomplish nothing. Learn to do agile right or cancel the meeting.

12. Formalism

Formalism is more than wearing a suit and can show up in unexpected ways. Ironically, casual environments are more difficult because establishing the line is harder, but developers have fought long and hard against formal environments. When I worked for JBoss, three directors of development in a row told me I shouldn't wear a dress shirt-and-slacks combo, and they would pay for me to buy decent clothes at Target. They were dead serious. The concern was that if JBoss (a perceived sandal brigade) showed up in a suit, management would eventually force the developers back into the penguin costume. The casual environment was, in fact, a synthetic construct. I tried setting the bar recently when hiring an HR manager who immediately asked, "Does this mean we can't say [the F word] anymore?" I replied, "No, [the F word] is a holy word, and we will utter it at any time, any place, and for any or no reason whatsoever ... unless customers are around."

There is a divide between the button-down environments and the no-button environments that crosses in to how people talk (such as dongle jokes) and how people think ("makes the most technical sense" versus "isn't in my territory"). Some of this is due to larger environments requiring more rules; other times, people love ceremony and excessive "formalism" in procedure, speech, dress, and more. Forcing developers to do everything inside the box for the sake of formality is the abuse of the mind and spirit.

13. Management by hostage crisis

Sometimes a load test will fail, and management may want to hear the root cause and a solution. They may even threaten to revert the changes, even if it breaks the implementation. This is a perfect path to knocking the development process off-track. Micromanaging and asserting authority from up high not only interrupts the normal iterative process of implementation and testing; it also makes developers afraid to try anything and attract unwanted attention. Threatening drastic and immediate destructive action to resolve problems without understanding the related functionality leads to a rushed product at best. Putting a project at the mercy of panicked customers or managers assures developers that the situation is out of their control, but they will be blamed for the outcome despite their warnings. Goals and deadlines guide work to completion. A thrashing whirlwind destroys it.

14. We ask the questions around here

Let's say someone finds a rogue machine trying to connect to Skype on a restricted port. The developer is unaware this violates the rules. But when asked about other guidelines, no details are provided. Congratulations -- you've just punished a developer for failing to adhere to vague, unannounced, or undocumented restrictions. Don't be surprised if this leaves them looking for the nearest exit.

15. Details, baby, details

Pointy-haired boss: "The customer asked for a tweak. Can you add that in time for release?"

Coder: "No. That would require a major architectural change. We asked before we started out, and we were told not to spend the time making that sort of expansion possible."

Though requirements are rarely set in stone at the outset, pressing developers to take the shortest path to them without accommodating for likely changes puts them in a tight spot when the demands come later.

16. Never mind how it works, just tell me how it works

Some managers demand immediate solutions to problems while simultaneously refusing to entertain hypothesizing about the causes and resisting efforts to investigate properly. It usually comes with verbal challenges to the effect of, "Aren't you an expert? Why can't you just explain or solve it?" To find a solution, you must investigate the causes, as well as hypothesize and test those hypotheses. No, we can't fast-forward to the end -- our problem-solving methodology will devolve into guess-and-check!

This article, "16 ways to torture developers," was originally published at InfoWorld.com. Keep up on the latest developments in application development and read more of Andrew Oliver's Strategic Developer blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.