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.