10 Ways To Fuck Up Your Software Project

We all know that software just writes itself. However, if you are willing to work really hard at it, you can still fuck it up.

Are you the person in charge of executing a large-scale software build? Then you need to know these 10 sure-fire ways to ruin a software project:

1. Be Vague.

   Always state what you need in as general terms as possible. If your team gives you specific requirements, always rewrite them into more general forms before giving them to developers. Developers love to hone their skills by rewriting the same components over and over again when you tell them it wasn’t what you wanted without first telling them what you wanted.

   ---

2. Ask For Quotes Before Giving Requirements.

   If you have an internal team, you’ll want time estimates. If it’s an external team, you’ll want costs. Either way, insist on those after the briefest possible discussion (nothing in writing) of basic requirements. If they insist on something in writing, don’t write more than can comfortably fit on one side of a napkin. Then hold your developers to those estimates. This ensures that the team spends half their time just finding out what is needed, and the other half doing everything they can to squeeze the work into insufficient time. The result will be a wonderfully crap project with an excitingly low quality ceiling, and general depression and ill-will between all parties.

   ---

3. Always Make Changes After The Plans Are Locked In.

   A professional team will make you pay for late changes, but that is ok. The main thing is to provide significant key changes after the solutions have been architected, thus ensuring that the delivered project will contain plenty of “tacked-on” elements, that it was never designed to incorporate.

   ---

4. Change The Direction of The Business During Development.

   If you are building a product for a certain target market, try to change your market during development, and instruct developers to “keep this in mind”. For example, if you are building an online community for financial planners, change your market to target foreign students instead.

   ---

5. Never Explain “why”.

   Don’t tell your developers why you need this project. Don’t tell them what it will do for its users, or for the business. Avoid sharing details about the reasons why certain features are needed. Thus your developers will be forced to stick to your own scantily-defined requirements as their sole source of knowledge about the purpose of what they are doing. This virtually ensures that you will get exactly what you asked for, rather than what is needed.

   ---

6. Always Hire Non-English-Speaking Teams.

   All developers speak “code” right? By hiring foreign-language developers, you will also save a lot of money, which is really important, because you will need it to pay for the same project 4 or 5 times.

   ---

7. Set The Timetable On Business Objectives, Not Work Involved.

   It is very important to be firm about your timetable. Always insist on having important milestones completed “for the presentation to Jim on the 25th”, rather than actually choosing dates based on the work involved. And try to do this once all the milestone timing has already been set. This is one of the best ways to ensure that each delivery is loaded with bugs, key features don’t work, and the things which do work were done early on, and have thus become unnecessary.

   ---

8. Avoid QA.

   Only bad developers need Quality Assurance checking. If you have a skilled team (and a quick check of their foreign university transcripts can tell you that) then you should not worry about QA. Also, you should insist that if any QA is done at all, it should be done by having the developers check their own work. Don’t let them check each other’s work, as that can sometimes lead to accidental productivity.

   ---

9. Don’t Research Your Needs First.

   One of the more subtle, yet highly effective ways to ensure project failure is to build the wrong solution. If you avoid basic preliminary research, you have a much better chance of crafting a solution that doesn’t take into account your market, your business case, your competitors, or the purpose of the solution. This way, even if a project turns out accidentally successful (it happens) it can still be rendered entirely useless.

   ---

10. Always Leave Things Unfinished.

    You should never fully

If you diligently take these rules to heart, you are almost guaranteed to fuck up your software project. Happy building!

If you think of any other ways to sink a development project, let me know in the comments below.