25 Ways To Make Your Software Development More Awesomely Crappy!

Andrew Wulf

• 3 min read
  1. Make everything as complicated as possible, if not more so
  2. Call everything Agile, especially the stuff that isn’t
  3. Plan everything in advance; make sure you get sign-offs from every layer of management, accept random deadlines, calculate the whole project’s story points long before you start anything and assume nothing will change
  4. Use as many teams as you can, preferably under unrelated VPs who refuse to cooperate with each other
  5. Try to not write code from scratch, better to buy a canned software package and then change every single thing it does
  6. To ensure quality put a junior developer in charge of enforcing quality who then downloads every single Java quality enforcement plugin that exists and turns them all up to max
  7. Refuse to hire employees and prefer contractors or enterprise body shops, preferably those with no knowledge of your business; for added bonus manage them with a contractor; even better fire everyone in your company who knows anything about software development and rely on the external contractor to tell you everything is fine
  8. Build apps from 100 different repositories managed by at least a dozen teams all with different schedules and agendas
  9. Refuse to hire any QA because programmers should test their own code
  10. If you hire QA hire random contractors in foreign countries who don’t understand your business, and hire them right before shipping to ensure maximum confusion
  11. Ensure all technical decisions are made by non-technical people; even better have them hire consultants at exorbitant rates to tell them what decisions to make; for added success have the non-technical people refuse to believe their employees but believe everything vendors say
  12. Always choose the coolest software tools that are incompatible with what you want to use them for
  13. Blame everything on programmers including hardware and networking failures, for added bonus assume all programmers want to put porn on your company’s websites
  14. Of course the best plan is to invest enormous sums of money on technology you have no use for then force developers to use it anyway to justify the cost
  15. Wait until the last minute to tell people that everything has changed and all their work was wasted because it was a secret you didn’t want them to know
  16. Believe the code people talk about is more real than the software you can actually see working
  17. Assume that all advanced estimates are accurate to the day and build all other schedules assuming this is true especially marketing plans you can’t stop
  18. Plan learning opportunities for your developers based on suggestions from your lawyers to minimize lawsuits
  19. Design application features based on suggestions from your lawyers to minimize lawsuits
  20. Have competing groups specify architectural choices developers have to use; for best benefit ensure they are incompatible
  21. Make sure all meetings include every single person in the company to make sure the only person who can do anything will be there; even better create multiple simultaneous meetings with overlapping required attendance
  22. Making decisions in large groups to guarantee blame will be spread thin when everything goes haywire; therefore the more people at the meeting the better
  23. When everything goes haywire make sure you have plenty of fingers to point in all directions so no one can tell who is really to blame; this is similar to how sardines school in large groups to confuse predators
  24. Hire people to manage programmers who have never even talked with one; for extra challenge hire them from such applicable prior positions as Maitre'D, Forest Ranger and Cashier
  25. Instead of shipping one thing ship everything you can think of in case you might need it; for extra credit demand the original schedule so everyone works like crazy; be even more amazing by then postponing the project at the last minute
    Armed with all this advice you cannot fail to screw up in an awesome fashion.
    Yes, I have seen all of these in some form or another over my 35 years, thankfully not all in one place. I bet most programmers can recognize the truthiness in this collection. Why develop good software easily with a minimum of fuss when you can fail in style!