An Alternative to RUP

I wrote this a long time ago on a Blackberry in a fit of frustration on a project…it still cracks me up

In an effort to reduce the strain on some clients who seem to have difficulty adopting the RUP process, I present to you an alternative methodology based on a model of what they’ve accomplished in the past and continue to strive for in the present.

First, schedule the project. Any project worth doing should have a deadline, and this needs to be set immediately after coming up with a catchy-yet-vague project name. Really import projects require the deadline to be set before the project is named.

Once a completion date is set, work backwards to build a full schedule. If the date is 6 months away, we know it takes as long to do QA as it did to code, so code freeze will be in 3 months. Everyone realizes that requirements need to be gathered, approvals gained, and designs considered, so let’s plan to do that at the same time. Just to make sure there is enough time to get it all done, give it 4 months. The math is clear: start the project last month.

Next, program something. Anything. We’ll find a use for it somewhere. Yes, we’ll give you requirements just as soon as we decide what the project is. And while you program, please create a design document to show that you used design. To make sure it is an accurate description, write it after you’re done coding. Also, please make all documents as boring as possible so others don’t waste valuable company time reading them.

Laugh maniacally to prove you are fully stressed. If you are stressed, then we have an accurate deadline. If you’re relaxed we obviously gave you too much time. If you’re just burnt out, you’re probably faking it. We have a perfect schedule, everything is on time, and if it’s not on time we can always change the requirements to be on time. We also reserve the right to change the requirements if we happen to feel like it. We’ll let you know critical changes during QA so you can add it in while you fix bugs.

Announce publicly the full functionality and the release date of the project. This should be done prior to QA. Also, to build public awareness and industry anticipation, announce that this service is availablet, program something. Anything. We’ll find a use for it somewhere. Yes, we’ll give you requirements just as soon as we decide what the project is. And while you program, please create a design document to show that you used design. To make sure it is an accurate description, write it after you’re done coding. Also, please make all documents as boring as possible so others don’t waste valuable company time reading them.

Test the application. Hey, we planned for QA early on, and we’re doing it! Be sure to only test the user experience, because this is all the public and our non-IT departments understand. If all of the data is wrong, that’s a production issue. The guys in production have nothing to do anyway, right?

Throw it away and try again. Nothing worked the way it was supposed to, no one uses the software, and we’ve identified a scapegoat (read “lead developer”). Bring in a consulting firm to fix it all. And remember, we have this process in place and we’ve used it before. It’s documented. So make sure the consultants follow this method.

Like any methodology, it needs a catchy acronym to be considered a real process, so lets look at what we do and see what it spells (we would never consider coming up with the acronym and then trying to make the process fit J):
Schedule
Program
Laugh insanely
Announce it’s finished
Test it
Throw it away.

So, there you go. As a viable alternative to the RUP process, I offer you…

SPLATT!