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.'"
Seriously, they give email to 'everyone'.. what they should do is give corporate email accounts to select people who have to deal with outsiders.
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.
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.
This type of stuff is why the government normally has so few qualified people.
:)
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
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
"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 that I can recall) but worth pointing out is that this childish nonsense actually increases in frequency with larger companies, where there is typically more room for advancement. The best way to avoid this shit altogether is, as you mentioned, to start your own company; however, that is not plausible for most people, due to financial reasons, not having business know-how, et cetera. Unions aren't necessarily the answer either, as your union rep may be in with the person out to fuck you over (this was actually the case when I worked for a large plumbing-products manufacturer in Wisconsin). That sort of situation is, in fact, worse than no union representation at all because you pay your union dues every month and end up getting railroaded anyway.
Back to your post now. I find it very telling that you chose the phrase "wrong attitude." You claim you are not a manager, but this is exactly the sort of empty phrase that managers use to cast non-asskissing employees in a negative light. "Attitude" is purely subjective; there is simply no way to quantify it. Therefore, any discussion of "a bad attitude" in regards to an employee's job performance can be interpreted as: "This person is good at what she was hired to do, but I don't want to say anything good about her because she doesn't kiss my ass." If it's true that you're not a manager, my guess is that you wish you were.
Sorry for the long post, but I think you're dead wrong on this one.
Writhe your naked ass to the mindless groove.
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'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.
If it's designed to fail, all the blame will be on you anyway.
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.
When it comes to blame, it's their documents vs your word. What is stronger?
The key is to make the trail contain what you WANT it to contain, no matter what the communication says. Email them "I predict that can't be done on schedule", then call them 5 mins later stating you caught a bug in your calculations and it can be done after all. The email remains, the call is gone.
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.
Yes, except - NOT TOO EARLY. First gain enough influence by quiet means. Then smash the others and remain on top. If you shout "Look, Daddy, Look at me!" you will get slapped by bigger kids really fast.
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."
This method gives your team and company automatically a long line of "maintenance and correction" opportunities. If they say Ethernet and you think "WiFi will be easier", prepare to crawl with the TP wire waist deep in snow in -30C because the WiFi antenna has frozen.
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.
You'll be the first one to blame.
Nobody got fired about choosing Microsoft. Implement any experimental technology and whatever fails in the project (no matter how unrelated) it will be blamed on the technology and you.
(BTW, IANAM--I am Not A Manager).
Yes. You're redundant.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
I think that this article is a huge reason why the "open source" model is working... not just because it is a development strategy that may or may not be superior, but because it is a political alternative to the sort of corporate politics that are almost inevitable in a capital/industrial environment. Econodwarf wisdom idealizes a competition as a deliverer of optimal performance... tighten the screws, and output increases. but the competitive mindset doesn't disappear when employees clock in. The pressure that drives companies to compete among each other can also generate the internal competition that drives this sort of political BS. And the more complex and collaborative the problem is, the more vulnerable it becomes to this internal ego jockeying. I conjecture that's a huge reason why we see politics playing such a deadly role in the development of software. The problem with the "economic incentive" model that we seem to hold as the solution to all of societies problems and the deliverer of all of our culture's wants is that the incentive emphasizes the wrong thing. It pushes us to promote ourselves, whether for the sake of vanity or survival, and the product that results is often merely byproduct. Better would be an incentive that drove each toward the collective goal. In free software projects the incentive, while perhaps somewhat vanity oriented, seems much more about loyalty to the creation itself. The systems may break down along less integrated lines, like two unrelated projects that mesh together after the fact for an unplanned-for synergy, like the LAMP platform, but less energy is wasted in painful CYA-like activity. Obviously not every project can be developed collectively like this. Any ideas on how the community spirit can be better harnessed in an environment in which the job is less fun? Managers, from my experience of layer upon layer of them, don't seem to be it. How do companies make people want to work toward the project working? Is the current, sad, mess of a situation the best we can do? What do developers suggest?
Oh, that's wonderful!
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 client decides C is redundant, D should be done in Y way and E and F are needed. So charge them for all that - it wasn't in the first specs...
Next time they will state clearly what they really want.
Remember: A correct program is not a program that does what the user thinks it should do. A correct program is a program which does everything (and nothing beyond) what the specification says. This is the only metrics. If you start guessing, you get the blame.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Very good description of the first principles. The projects don't matter, good design does not matter.
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:
You can't handle the truth.