Software Project Failure
A How-To Guide
This is a posting for all software development or project managers who cannot stand their job, detest their company, hate their life or any combination of all three and who are actively seeking revenge against all who have made their life so miserable.
One simple means of getting the revenge you crave, of exacting pain and torment on those around you is to guide your development project to failure and I’m here to tell you some simple little things you can do to your developers that will almost guarantee your failure…
Cast Them Into a Dark Dingy Dungeon
The first thing you need to do to your developers is the worst thing you can do to your developers.
Restrict internet access.
Simply claim to your manager that your team wastes too much time on the internet so a restricted policy is required. Tell them to lock down access to all sites except those authorized by you personally.
Then don’t authorize any except Google…that way your team may still search for answers to their technical question but never get to the actual answers (evil laugh). Of course, tell them you are talking to your management to have this restriction removed.
If that is not possible, simply ensure that your team has the exact same restrictions as the rest of the company, that is usually enough to cause major frustration, especially if they cannot download anything (they like to download all sorts of helpful things).
Gouge Their Eyes Out With a Stick
Whenever a team member asks for an additional monitor or even just a larger monitor, be ready with your new favourite saying (you will be using this alot);
“sorry, there’s nothing in the budget for things like that”.
Larger monitors and especially dual (or triple) monitors often lead to increased productivity and worse, makes the developers job more enjoyable so you must be very vigilant in keeping them restricted to one monitor…preferably a 14 inch number.
If anyone ever asks you:
“may I bring in my own monitor from home then?”
immediately ask them to pack their things and be on their way. This kind of ‘go the extra mile’ behaviour can be infectious and may allow a thread of work enjoyment to seep into the team which, naturally, is intolerable.
Strap a Giant Ship Anchor to Their Waist
Developers think they are special. They are not. As such they should have the same machines as everyone else in the company. If they say they need a more powerful machine, tell them if they were a half way decent developer they should be able to work with any old machine, even a 386 just like you used to do back in the day…
Ensure any servers you have are maxed to capacity, especially the database server, there are few enjoyments in life that beat watching a developer lose more hair because the database server has run out of disk space…again. Crying, “I have more disk space on my mobile phone than this stupid server…which century are we living in here!”, they will beg for a new machine or at the very least a bigger hard drive. Enjoy the show and once they’ve cleared some space and got things working again, copy a massive file onto the server and watch the spectacle again.
Oh and of course if they happen to have a build machine, make sure it is the slowest machine you can find. A slow build is a frustrating build and a frustrating build is easier to get rid of (you want to stop any continuous integration which may be going as this kind of setup takes away ALOT of developer pain).
The beautiful thing about this is you will be seen as a genius by upper management because of the vast amounts of $$$ you appear to be saving them! Secretly laugh at them behind their backs because the reality is very different, though they are saving money on better machines, developers are taking 2-3 times as long to complete their tasks…and developers are expensive…much much more expensive than ‘decent’ machines.
Start planning an amazing holiday, your bonus should be huge this year!
Divide and Conquer
If your team gets together on Monday mornings for a coffee and a chat about the week ahead, it may seem like a good time waster to you but don’t be deceived! Such meetings are great for morale and team building, making your team happier and therefore more productive.
They must be stopped at all costs.
Watch your bonus grow as you put a stop to these ‘meetings’, putting an extra twenty minutes of work back into each developers Monday. Senior management will be talking about your genius.
Bore Them to Tears
Documentation, Documentation, Documentation!
Reams of it!
Any new feature request demands at least a few pages to fully describe the change…and that is just to fix some spelling.
As for the developers. Insist on a tech spec for every piece of work. Then insist that spec must be approved by the team lead…before it goes to the architect for approval…which then must finally be approved by you. Make a point of rejecting at least half.
Ensure the documentation gets done in something like MS Word. The business (and senior management) will be happy with your choice and developers will grumble.
They do complain alot, developers.
They will grumble and tell you that a Wiki would be a better place to document things because it’s easier to search, keep updated, manage change history and ensure that the latest version is easily available to everyone. Indeed they are right but that would involve change and who wants change? Change means risk and you have a bonus you are working towards.
Drive Them Insane
Say things like, ‘ok, to improve productivity we are going to be doing daily SCRUMs’ (developers love SCRUM’s, well good ones do anyway).
But then in each meeting YOU do all the talking, dish out tasks, berate people for taking too long, tell them how poorly the team is perceived by the rest of the company then finish the meeting with a (contrasting) positive and resounding, “OK team, Let’s go GUYS”.
This is so completely not how SCRUM works. Your good developers will point this out…make sure you keep calling the meetings a SCRUM and they will slowly (but very surely) go insane. Eventually they won’t be able to stand it any more and will leave.
Tell senior management the deserters couldn’t handle the new tighter controls you have placed on the project and replace any good developer that leaves with one that is half the salary.
Get an extra bank account, one is not going to be big enough to fit your bonus!
Give Them Enough Rope
WARNING this is pure evil…so read very carefully.
Allow on the fly changes to production servers.
Grant full access to production databases, i.e. so developers can run any kind of script at any time.
Like a spider in a web, you just sit and wait…disaster will happen.
Throw Them to the Lions
If senior management approach you about problems they have been hearing about the system, always direct all blame to the best developer on your team (if he/she was so good the problem should have never arisen).
Deny all suggestions that your team has been doing many extra hours (with no overtime paid) to stay on top of things, suggest that even if that were true, once again, if they were half way decent developers extra hours would not be needed.
You are doing the best you can with the limited abilities which exist in your team.
If you start to feel uncomfortable with how you are treating your staff (what the!), just remember…your bonus.
The Perfect Team
Do all of these things and over time you will find that strangely not all of the developers leave! Some stay on enduring the pain, walking the tightrope over the raging river of suffering. No matter what you do they keep coming back for more and the great thing is this, they do not leave because they are rubbish, they have as much talent at software development as you do at managing projects, are entirely in it for the pay packet and are slowly but surely turning your codebase into a festering cesspool of ick.
So keep up all the good work you have been doing and your team will soon be full of these blundering fools and you will have complete success at total failure!
I just wanted to be clear here, this is not a rant about a place I have worked and most certainly not about any individual manager. Just a bit of fun exaggerating some of the frustrations we have all experienced as developers.