How to kill a project

Question

Just looking for some collective wisdom -- what's the best way you've found to kill a project. For example:

• Change architectures half-way thru coding.

• Add new programmers to team when project is starting to fall behind schedule.

• In an effort to save money, force all developers to use old equipment and stop providing free caffeine.

Answer 1

A commercial/manager who change/add the specification/feature of the software and decide when it must be released without consulting a technical expert (senior programmer).

Answer 2

Tell developers that there's not enough time to write unit tests for their code.

Answer 3

Getting started on a new project (If you're programming for a hobby atleast).

Answer 4

Start rewriting a working application from scratch. Or at least start refactoring the life out of some of the core modules of a complex system. This should be done without unit tests for either the legacy or the new code.

Answer 5

I have had users look at the near finished product in user acceptance testing and start listing off changes that they want. Of course, these changes are usually major but to them it's "just text on the screen". Tell them the deployment date will have to me moved and suddenly I am incompetent. I have been on many projects where that last 10% never gets done.

Answer 6

Follow the standard Duke Nuk'em Forever project management model.

Answer 7

1. Blame management for every thing, and become disgruntled and start telling your coworkers how much it sucks working on the project. Then do nothing to change your own behavior. Then go home and sulk about how if only you worked at a place that "allowed" you to program the "right way". Then Let other dictate the quality of code you write, and take none of the responsibility for it.
2. Fall for the quick hack.

Answer 8

In my experience, projects that don't follow the normal procedures and rules of software development are prone to excessive delays in completion. By normal procedures I mean software projects that don't follow a Software Development Lifecycle; projects that are "rushed" by management because they just need it now; projects that don't ever have requirement documents or specifications attached to them; projects that don't go through iterative phases of testing, and the list goes on and on. Basically, any project that is half-(insert your favorite anatomical description here) is doomed to hang-ups and possible failure. There's a reason that procedures such as SDLC have been found to actually work, yet years later we still haven't effectively managed to convince many would-be managers, project leads, project managers, what have you, that they work when done right.

Answer 9

Adding new people to the project when it starts to slip is a sub-optimal way to kill a project. You need to make sure that the new people are expensive contractors on short-term contracts (3 months or less). This ensures that they occupy the time of the existing staff when getting up-to-speed but don't hang around long once they are useful (at that point they should be replaced by new contractors).

Additional Techniques for killing projects:

1. Give the most critical pieces of work to the least experienced people, they tend to be more willing to try things that are ill-advised or just impossible.
2. Encourage people to work 80+ hours a week so that next week's productivity is minimised.
3. Don't test anything.
4. Enforce Dilbert-esque technology restrictions. Don't let knowledgeable people choose their tools.
5. When recruiting remember that the goal is to find a "warm body", don't let choosy people do the interviews.

Answer 10

Ignore existing, mature solutions/products that would solve a lot of your problems because you convince yourself your needs are just different enough to warrant a custom solution. Ignore the fact that this custom solution will need months of testing that you don't have.

Answer 11

Choose the path of least resistance for every decision you make, design-related or otherwise.

Answer 12

Not using a VCS.

Answer 13

email you coworkers links to amazing PORN videos you searched ... everyday before the office starts