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

Government

[digitalchinky]

The good thing about arse covering is that it works both ways - management send you a metric crap load of hate mail, store it, print it, keep it.

Management meeting, threatened to sack you for simply existing, sideburns too long, whatever.

I've think I've been on both sides of the fence long enough to know government is about running favors for each other.

CYA can be a dragged...

[__aaclcg7560]

Covering Your Arse (CYA) was a big thing at the last company I worked for. Being a lead tester, I had to document everything that could be used against the developer to put the blame on them if the project screws up. The developer was also doing the same thing to me. That made crunch time in the last two weeks of the project particularly difficult since we're being nice and stabbing each other in the back at the same time.

The department manager has the option of casting the blame on the lead tester and firing him if QA loses the blame game. I didn't like that option and documented everything that the manager did (but usuually didn't) do to protect my job. One manager got himself promoted out of the department because he thought I was going to get him fired on numerous occasions. (Not surprisingly since he was trying to screw up my projects to get me fired.) The next manager wrote me up for insubordination when he found out that I was documenting his actions when he explicitly told me not too. I quit my job soon after that. After six years of that crap, there has to be something better out there.

Re:CYA can be a dragged...

[NateTech]

This all comes back to the fact that most management can't seem to learn -- you shouldn't have a job.

Sorry, but Quality Assurance is an attitude, not a department.

Making it into a Department is a sign that people actally WANT someone to blame everything on, instead of taking the correct amount of time and resources to design and build correctly in the first place.

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

[plover]

Lots of companies have had the problem mentioned in the article. While it's not exactly "censoring", ours has set up Exchange server to DELETE email older than 30 days, and called it a policy.

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.

Talk about a clusterfsck. My problem is I get documentation in emails, and that doc gets wiped after 30 days if I forget to save it somewhere.

What a good article

[turgid]

That is a really good, well-written and insightful article. I wish I'd seen it 10 years ago.

You young ones would do well to read it carefully and think about it. It will help you not only to survive but also to move up the food chain.

Remember, if you do things "right" in your current job, even if you get fired for it (i.e. keeping a record of your work, achievements, problems, conflicts, etc.) it will help you when you go to get your next job.

You can be choosy about who your next employer is.

A good idea is to be a member of a professional organisation, such as the Britsh Computer Society, where you can achieve recognition for your efforts as you go along. It's more evidence to take with you when you go looking for a new job when the inevitable happens.

Politics is typical for the US

[bvankuik]

I'm working for a North-West European branch of a large multinational with HQ in the US. The general opinion here is that the game of politics is played by the Americans. When we are at work without them, we just do our jobs and if the project fails, it's the fault of the team and not one of its members. Any disagreements or irritations (which WILL come out when the going gets tough) are treated with extremely blunt honestness; first discussed in private to get the sharp edge off, then in the team.

Yes, that includes QA saying things to developers like "you don't even smoke-test your work and I'm NOT going to do that for you", or (developer to manager) "why do you ask with what I'm busy? You're the project manager".

Of course, you have to let some steam off once in a while by joking and horsing around.

Re:Politics is typical for the US

[Anonymous Coward]

I work in the US branch of a large multinational based in Europe. We blame all our PHB problems on the Europeans.

My guess is that in both cases the source of politics isn't the location of the global headquarters, it is the headquarters.

Re:Wrong Attitude

[KontinMonet]

I am a manager and I have seen this sort of politics all too often. SWAN is all very nice but unless you have support all the way up the chain, you end up spending vast amounts of time fending off back-stabbers, however SWAN you might be.

Phone is better than email, but email must be used when people outright lie about what took place. If you confront people who are simply out to sabotage your every effort (perhaps because you got 'their' job), email trails and signed off notes in meetings followed by an email listing actions are mandatory. Otherwise, the job will not get done.

Most people in this business strive for well-developed, flexible and accurate software. Unfortunately, 95% of the time, for some reason we inherit hurried, buggy and inflexible software. And we (as managers) are still expected to perform miracles in very limited timescales with despondent developers. Telling senior management you'd like 9 months and another 1.5 million to get their piece of shit looking like a shiny gold nugget just doesn't go down well, however diplomatically you put it.

Use cases work well if they are targeted correctly. They can be very useful as an overview of the system to users. 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.

Innovation is all very well, but it has to be relevant. As a manager, if there is a lull, there is nearly always a ton of other things that have more priority.

Finally, in my experience, most management in the software filed is dire. For example, in one place when I arrived, a project was already going badly. I had senior (and board level) managers coming to my teams and asking them to 'do just this little bit of documentation' or 'fix my laptop'. Senior managers who know just a little about software decided (over my objections) that the team should fix bugs their way (ie the stupid way). They would arbitrarily move people between teams working for different clients (again over my and other people's objections). It all ended up wasting large amounts of my teams' time in critical situations. On those occasions when I pointed out and proved time was being inefficiently used, I got flak for not being a 'team player'.

After nine months of this crap despite repeated pleas and discussions and explanations of why they were jeopardising the project, the CEO started a 'blame hunt'. In a crisis meeting in the board room, he pointedly asked me that if the project slippage and possible loss of a big client was not my fault, then whose was it?

By now, I'd had enough of diplomacy. He was not the one facing the ire of the client on a daily basis, I was. So I said it was his fault. I hadn't hired the people who were screwing up this project, he (and other senior management) had. If the buck stopped anywhere, it was with him.

I expected to out of the door that day. After they found out what happened (this stuff rarely stays quiet), my teams and co-workers expected not to see me the next day either.

What actually happened was that the owner of the company (who was in another country) sort of agreed with me. I outlasted the CEO and a number of the senior management. But, unfortunately, the damage had already been done and we lost the big project. I moved onto other things in the company and saw the owner a lot more. The company started going through a bad patch and shrunk considerably. Other parts were being poorly managed too. I saw the writing on the wall and jumped ship.

Re:Sounds good, but far from air-tight advice...

[fishbot]

That's a dangerous line to tread, because there's a third option: someone who identifies a problem at the last minute and can't fix it in time is shortsighted and incompetent.

Sadly, that's why if a problem is found at the last minute and cannot be immediately fixed by the finder, it is never mentioned and the product ships, bugs and all.

In my varied career as various types of software developer (web, database, UI, engineering, etc) I have found that the single most destructive force in software development is fear of retribution by clueless idi^H^H^Hmanagers.

When an engineer cannot create without being labelled a disruptive force, cannot mention known problems without being labelled a trouble maker, and cannot ensure quality without being labelled incompetent, it is a sure sign the the prime reason for software failure is incompetent management who do not understand the, how shall I put it, unique mindset of the average engineer.

Visible unpaid overtime

[eric76]

Keep to the minimum possible. Remember that the earliest part is most valuable since there are more witnesses: better to do half an hour Monday to Thursday than two hours on Wednesday. It also sounds better to say: "I've worked late four nights this week." No-one will be keeping track that closely anyway.

At my first job out of college, being in a strange town with nothing to do anyway, I would routinely work late. When I left, instead of going down to the bottom floor, signing out, and then walking up several flights of stairs in the parking garage to where I was parked, I would just exit through the fire escape and walk down to where I was parked.

Then one day I walked into the senior vice president's office and saw him looking at the night and weekend signin/signout log maintained by the guards on the first floor.

After that, I always went down to the first floor and signed out.

And it worked. One morning I really overslept and came in about 11 am to find a note that I needed to report to the senior vice president's office.

So when I went in to report, I apologized for being so late. He told me not to worry since I worked late so much of the time.

Re:Visible unpaid overtime

[eric76]

In my case, it was really two things:

1) I didn't have much else to do. I wasn't into hitting the bars nightly and I didn't want to sit around watching tv. Also, I only knew about two people in town (a couple of cousins) outside of work).

2) I didn't necessarily spend all the time working. At the time, home computers were barely out, but I was too busy paying college debts to afford them.

Those home computers that were affordable like the Radio Shack Color Computer weren't very attractive to me. What I wanted was a PDP-8 for home, but I just couldn't afford it.

So I spent part of my evenings at the office figuring out how to really use the company's PDP-11/70 with RSTS/E.

---

For example, we really needed more computing power when I arrived. The PDP-11/70 just wasn't enough. The funny thing was that it was only using about 30% of the CPU under heavy load. Most of the time it was waiting for disk accesses.

We added 1 megabyte of memory, but that didn't make any difference.

I experimented with disk caching. Under RSTS/E, you could either turn disk caching on for everything or just for selected files. Turning it on for everything didn't improve much apparently because you didn't have much memory to really cache much.

But I dug through all the documentation and was appalled at how the disk caching worked. A minimal cache time of 30 seconds was defined. In other words, when you cached a disk block, it was there for 30 seconds before it could be removed and so there wasn't enough room to cache most disk accesses. Even allocated much of our new memory didn't help.

So late one night, without telling anyone what I was going to do, I patched the operating system to change the thirty second cache time to five seconds. The results were phenomenal. We went from 70% CPU idle time to 0% CPU idle time. Since the vast majority of the cached disk blocks weren't needed after a few seconds, keeping them there thirty seconds was just blocking additional disk blocks from being cached. Caching all disk reads for five seconds had a phenomenal positive impact on the computer.

When adding disk blocks to the disk cache, the algorithm would first remove any that had been there longer than the maximum cache time. So after patching the system to change the cache time, it was useful to observe the amount of memory used for the cache for a day or two and then adjust the maximum disk cache time up or down. If it was full most of the time, reduce it slightly since there were likely to be eligible disk blocks that weren't being cached. If it was not full, increase the time slightly until most of the memory allocating for the disk cache was being used.

Modifying the disk cache time did lead to one problem.

My boss didn't really understand computers much. When certain employees would complain that the computer was too slow, he'd up their priority.

Before the disk cache time change, it made little difference because their processes still had to spend much of the time waiting for disk accesses. After the change, increasing the priority would allow the one process to use nearly 100% of the CPU time until it finished. Noone else could run anything -- it was as if the entire computer was frozen.

Of course, everyone but my boss and the people who would get him to raise their priority hated this. But once he had raised the priority, it might take an hour or more to get enough CPU time to drop the priority back down.

So it was time for another late night modification. I modified the utilty (correctly spelled - it had to fit in 6 leltters) program to act like it had raised the priority without actually doing so.

Then everyone was happy. Someone would call my boss and he'd raise their priority. They were happy because their job would finish faster and he was happy because he'd look better to their boss. The rest of us were happy because we could still get our work done.

I told a number of other RSTS