Politics-Oriented Software Development

thelesserbean writes "Up at K5 there's a tongue-in-cheek look at the dirty world of software development's inside politics. Presented as a guide, it is actually full of useful advice and lessons learned the hard way. For instance, in the 'Ass-Covering' section, we read: 'The chief difficulty is reaching a satisfactory compromise between ass-covering and not appearing too negative. (...) The emails you sent will be used in evidence against you. Keep a professional tone: before sending any sensitive email take a moment to think how it would look at an industrial tribunal.'"

Comments

Re:I'm surprised corporations don't censor email m

[Bill Dog]

Nobody can pull out the old emails and pull a trick like this if they've been deleted. And if you save them, you're violating policy, so you're screwed either way.

Run away, if you can, from places like that. TFA says to keep a daily record of what you've done. I've worked at a place where that was violating policy, and was a firable offense. Needless to say, I ran away, when I could. (They also prohibited managers from saying anything good about people on their reviews (I'm not joking or exaggerating) -- basically, they wanted to be able to fire you in a trouble-free manner, and they wanted you to help!)

Wrong Attitude

[cowtamer]

This article is quite exemplary of why software developers (i.e., "The Slashdot Crowd") have very low credibility with management.

It is not because they dislike management (although I am sure that has some role). Nor is it because the Machievellian environment described in the article is inaccurate. It is because they prefer complaining about problems to solving them.

Here's my version:

"Politically Oriented Software Development"


0) Don't Tick Anyone Off


1) Be Smart, Willing, Able, and Nice to work with (SWAN)

2) Don't add negative value. Remember that you are being paid to help your group/company make money. If this is not kosher, move on and join the Peace Core.

2) Avoid sending e-mails whenever possible. If you must, keep them extremely neutral. Use phone calls and personal conversations for any type of discussion or criticism--technical or otherwise.

3) Make sure your work is visible, and helps your group's visibility. Well developed, flexible software that meets the customer's needs provides the ultimate visibility.

4) Disabuse yourself of the ridiculous concepts of "Customer Requirements" and "Use Cases." They will not come. If they do, they will mutate into uselessness VERY QUICKLY. Avoid people who believe in such nonsense. Instead, thoroughly analyze the problem, the customer, and the market and create your own "requirements."

5) Innovate. Do "cool stuff" (prototypes, new concepts, algorithms, research) whenever there is a lull. If you do not do this, you will either get replaced or doom yourself to a life of mediocrity--probably both. Leverage the "cool stuff" at an opportune time to help your group.

And if you think management is unnecessary (as many commenters on K5 seem to), go ahead and start your own _successful_ company.

(BTW, IANAM--I am Not A Manager).

Re:Wrong Attitude

[johnjaydk]

And how am I supposed to write my own requirements when the customer has a very different view? Customer requirements are a result of back-and-forth discussions, they know the market and the process better than you do.

I have a very simple system for figuring out requirements.

First throw out the spec. it's either written by the users (and they don't know how to write it) or a manager (who don't have to write the code himself). Anyway the spec is wrong incomplete and misleading.

Go see the users themselves (great excuse: I need to clear out some details) and have them TEACH you how to do the relevant part of their job. Then you know the environment, the lingo and get into a ping-pong on requirements and possibilities. This part can easy turn into the most interesting part of your day to day work and you end up knowing your business top-to-bottom.

Second: The version 2 excuse. Promise two releases: rel 1 that only covers the bare essentials and rel 2 that covers the whole shebang including a gold-plated kitchen sink. The trick is to be agressive about moving features to rel 2 and focus on rel 1. When rel 1 is rolled out only the morons will complain about the missing sink or it's lack of gold. These morons are easily marginalised in a debate on return on investment on sinks wiht gold plating.

These methods only works on reasonable small projects for inhouse consumtion. YMMW etc.

Re:Developers! Developers! Developers!

[Black Noise]

Enjoy

Re:CYA can be a dragged...

[__aaclcg7560]

Maybe the prior poster actually did that.

That manager wouldn't put anything in writing. I wanted him to put in writing that I was required to work 80+ hours, seven days a week until my project was done. That, of course, would be in violation of the company's 60 hour/six day policy.

About one-third of the department was trying nail the manager on anything, and (last I heard) about half of them choose to leave instead. Upper management isn't doing anything since the coporate office loves the manager's bottom line results. It takes a while for results of experienced people walking out the door to show up on the bottom line.