Slashdot Log In
Politics-Oriented Software Development
Posted by
michael
on Sun Jan 30, 2005 02:05 AM
from the trust-no-one-keep-your-laser-handy dept.
from the trust-no-one-keep-your-laser-handy dept.
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.'"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
HAHAHAHAH (Score:3, Funny)
I thought you meant... (Score:2)
here [sourceforge.net]
(With apologies for the blatant plug.)
bad philosophy... (Score:5, Funny)
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.
Developers! Developers! Developers! (Score:2, Funny)
Re:Developers! Developers! Developers! (Score:2, Informative)
Enjoy [ntk.net]
Re:Developers! Developers! Developers! (Score:2)
Dave
Education (Score:5, Insightful)
Re:Education (Score:3, Funny)
I learned the hard way that telling management to get their own fucking coffee made me public enemy #1. Good developer vs bad developer only lie in between how well you handle firedrills and fetch coffee.
Re:Education (Score:3, Insightful)
Re:Education (Score:2)
Re:Education (Score:2)
Re:Education (Score:3, Insightful)
Sounds good, but far from air-tight advice... (Score:5, Insightful)
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.
Re:Sounds good, but far from air-tight advice... (Score:2, Funny)
Re:Sounds good, but far from air-tight advice... (Score:2)
Re:Sounds good, but far from air-tight advice... (Score:2)
Re:Sounds good, but far from air-tight advice... (Score:4, Funny)
Parent
Re:Sounds good, but far from air-tight advice... (Score:3, Interesting)
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 developme
Government (Score:3, Interesting)
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.
Re:Government (Score:2)
CYA can be a dragged... (Score:5, Interesting)
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... (Score:4, Funny)
If a manager asked that of me, I'd ask for it in writing.
Parent
Re:CYA can be a dragged... (Score:3, Funny)
So he went out and bought a tape recorder and took it to the office.
Whenever his boss came in to his office, he'd turn the tape recorder on and hold the microphone up for his boss to speak into.
His boss would get pissed off and turn around and leave.
Re:CYA can be a dragged... (Score:3, Interesting)
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.
Politics is typical for the US (Score:3, Interesting)
Yes, tha
Quite good article but forgot the main reason. (Score:5, Insightful)
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.
Re:Quite good article but forgot the main reason. (Score:2)
Unfortunately the "Peter Principle" and other sources of people who are not qualified are well and alive.
Qualified people (Score:2, Insightful)
The brainiac folks know how insidious politics like this are, and simply wont put up with working at a place that doesnt judge you on your skills.
Its just a theory, but it explains an awful lot
Re:Qualified people (Score:2)
It's the best job I could ask for, save that the pay could improve. I have a great deal of flexibility, my work is appreciated and used extensively, and I've had enough time in between projects to write widgets that can be used in future programs, thereby reducing the time needed for the next project. I've worked there four years, starting with my freshman year in high school.
Read 'em and wipe. (Score:2, Funny)
I work in the toilet-paper industry doing software development. I know all about ass-covering.
nothing new (Score:5, Insightful)
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.
Re:nothing new (Score:2)
Misleading title (Score:4, Funny)
What a good article (Score:3, Interesting)
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.
Wrong Attitude (Score:4, Informative)
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 (Score:3, Insightful)
"Roll over and take it in the ass."
I have had jobs in restaurants, factories, warehouses, IT, and even telemarketing, and almost all of my past employers engaged in the sort of disgusting behavior described in the article. It's never enough to just go to work, do your job, and go home. Some insecure prick above you will not stand for it and will do whatever he can to get rid of you, legal or otherwise.
One of the things not mentioned in the article (at least not th
Re:Wrong Attitude (Score:3, Insightful)
0) Don't Tick Anyone Off
okay.
1) Be Smart, Willing, Able, and Nice to work with (SWAN)
Be the pack mule of the team. Remember the budget rule? Spend less than your budget, have your budget cut next year. Slightly overspend and you have a chance for your budget to be extended. Same applies to work load. Do everything on schedule and next time the schedule will be tighter. Show you're willing and able to take project A and they will give you project B because it seemed you'd have too much slack.
2) Don'
Re:Wrong Attitude (Score:5, Interesting)
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.
Parent
Re:Wrong Attitude (Score:2)
They should be the result of back-and-forth discussions. However sometimes the customers don't know, sometimes they can't tell you, sometimes they won't tell you[1].
I've just completed a chunk of work like that where the lead analyst had to basically, by prior knowledge and guesswork, work
Re:Wrong Attitude (Score:3, Insightful)
Write down every piece of the bullshit the customer says.
Then write the program EXACTLY to the specs.
And when they complain, write down everything again, and charge them a nice $$$ for "program extension" over everything that you do that wasn't in the original specs. Point it out exactly.
The original contract was that the software does A, B, C and D, and D is done in X way. (though obviously it's stupid. You might have suggested it's stupid, but accept it if klient disagrees!) Now cli
Re:Wrong Attitude (Score:5, Informative)
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.
Parent
Allow me to edit your treatise. (Score:2)
The two most important points you made were:
What the customer wants and needs is paramount. Everything [and I mean everything] else is bullshit. Your job exists for the sole purpose of satisfying the customer [at a price that's profitable to the enterprise].
This is the most important point, an
Incremental dev. and time lines (Score:3, Funny)
After that, they hurry down to the development departments and after some panicky discussion and massaging of the project sheet, decide that Release 2 will happen 9am Nov. 15th. So yes, you do end up de-scoping during development. I have deliberately targeted sections for de-scoping and I am sometimes deliberately vague about will be delivered (rather than adding 40% contingency). For example, administrative functions will be delivered (but they might not have the gleaming front-end that they expected). And anyway, I get lumbered with a development team cobbled at the last minute (gotta save costs!) from half the losers in the company and a prima-donna who just sneers at the usefulness of unit testing and documentation.
Managers have surprisingly little power to get the best people for the job. When a board level manager decides that all sourcing will be now be internal, instead of the shit-hot guy I interviewed the day before, I now have to persuade a luke-warm candidate who really didn't want to move, to relocate 800km. Senior managers so often think people are like PCs. Roll 'em in, plug 'em at the desk, they start being productive that morning! Project finished (well,sort of)? Roll 'em out, there's another desk waiting.
Visible unpaid overtime (Score:3, Interesting)
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 (Score:5, Interesting)
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
Parent
Personal vs. Collective Motivations (Score:2, Insightful)
TFA is very good (Score:3, Insightful)
All that matters is what is easily visible and even more importantly - the perception.
-disclaimer-
I am a contractor, worked as a contractor for the past 4 years. Prior to contracting I've done 5 years of permanent work. I live and work in Canada, Toronto. In the past 4 years I worked at 6 different organizations on a total of 18 contracts.
--
The goal of any contractor is to find a well-paying contract and to make sure that the job is done satisfactory, so that the contract maybe extended for other projects within the same organization (hopefully for more money.)
My latest contract is quite interesting in that it is with an organization (no names) where the tactics are very close to those described in this submission. I was hired because a different architect was let-go (the union will not allow contractors to stay for more than 2 years,) and there was an important project to be done (the project is a legal obligation to the government, so it's serious.)
The overal feeling within the department is that the head manager of the department is a micromanaging, self-indulging, brainless moron with a serious attitude problem. From point of view of this k5 story, this is the only IT department, so there is less competition between the management on the higher levels to compete. But there are many other problems. The air within the department is that of complete secrecy.
You probably know the expression: job security?
Well, everything around here is based on that. The projects' success does not matter. The effectiveness does not matter. Maintainability does not matter. What matters is that you do not do what you are not supposed to do, even if it takes you 5 minutes instead of waiting for the specialized help for a week. You do not invade into the very narrow spaces of very narrowminded people, who are good at one thing - maintaining their job security.
Documentation to the projects is obviously outdated and has nothing to do with the system that needed to be improved upon. The system itself is based on technology (from a well known company) that should never have been used, but someone's ancle/aunt/father/brother whatever helped this tech to be pushed into the environment (obviously this tech is so obscure and specialized that noone else in the world uses it, so it's not updated.) The project is understaffed, the deadline is too damn close and the resources are not there (not enough money)
--
As a contractor I am interested in the project succeeding and as a developer I am interested to make sure that the design and development are based on some good principles.
So here are the problems (obstacles) to success and the steps I had to take to go around them.
1. The sources of the original system are controled by a special team. To gain access to the source control system there are too many obstacles. The advice to me was for our group to use a shared directory as a source control tool. Obviously this would not have worked - we would have spent all our time synching the sources. There are very serious barriers to getting a different source controlling tool being installed on a dev server.
solution: install a source controlling tool on your own machine. Import the sources. Set up you developers as users. Don't forget to make sure that the master source gets backed up somewhere every night.
2. Documentation to the original system is not good at all or non-existant. Knowledge is power and power is not to be shared with anyone. The tools for documentation control are out of reach.
solution: install a Wiki server on your machine (I use Tomcat and JSPWiki, it's good enough.) Start by setting up project space in Wiki, create sections for requirements, design, testing, assumptions, team, migration, issues, resources, standards etc.
Always update Wiki. Nothing must get past it. Remember:
Re:I'm surprised corporations don't censor email m (Score:5, Interesting)
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.
Parent
Re:I'm surprised corporations don't censor email m (Score:4, Informative)
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!)
Parent
Re:Evaluation (Score:2)
Metrics for this can be pretty vague and subjective. I found that I had to work with a team for at least a year before I could allocate numbers to: 'DB design', 'problem solving', 'accurate testing' or whatever.
Having said that, a proper evaluation also needs un upward component. Is the manager managing fairly? Is the team performance poor because the manager imposes stupid requirements? etc.etc. I've yet to see a company embrace