Slashdot Mirror
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.'"
One of the very first posts for this story at kuro5in was "Oh man, I bet slashdot is going to pick this up".
Now, if you're a sadist like me, that is probably *not* a good question to ask yourself. Or, at least, I can think of all sorts of stuff to write in my emails that would be friggin' hilarious to hear publicly recited by a no-smiles lawyer at an important tribunal.
When things get complex, multiply by the complex conjugate.
You know, universities should pay more attention to real world scenarios like this. Maybe then there would be less effort on screwing with politics, and more on doing a good job. Oh well, just add this to the list of things fresh programers get slaped with right out of college.
From the article:
Also remember that someone who points out a problem early is a troublemaker; someone who fixes a problem at the last minute is a hero.
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.
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.
The only part that I really disagree with is the first point 1. Most software fails because it is designed to fail
By the quite long experience the real reason why projects fail is much simpler: STUPIDITY
Be that stupidity of those who defined the project, stupidity by those implementing, stupidity by the management, stupidity by the client, stupidity by subcontractors, stupidity by equipment providers, stupidity by...
I am sure you get the point.
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.
John
i might get modded down for this but the thing i find most interesting is that so many of the points being attributed to software-development in the article seem to be applicable in any project in any environment.
i help out in a school district and every single meeting i go to has me thinking about the same types of things. who is in it for education's sake and who just wants a feather in their cap?
maybe it's more of a human element that just happens to be looked at here in the context of programming.
Keep the faith, share the code
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!)
Attention zealots and haters: 00100 00100
Politics-Oriented Software? Oh... I thought it was about the developement of something like Campaign 84 for the Colecovision...
Circumcision is child abuse.
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).
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.
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