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.'"
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.
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
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.
Did he inhale?