16 ways to torture developers

Hi, my name is Initech, and I have a developer abuse problem

Page 2 of 3

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."

| 1 2 3 Page 2
From CIO: 8 Free Online Courses to Grow Your Tech Skills
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies