2017年/01月/06日
25个方式让软件开发糟糕
Make everything as complicated as possible, if not more so
Call everything Agile, especially the stuff that isn’t
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
Use as many teams as you can, preferably under unrelated VPs who refuse to cooperate with each other
Try to not write code from scratch, better to buy a canned software package and then change every single thing it does
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
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
Build apps from 100 different repositories managed by at least a dozen teams all with different schedules and agendas
Refuse to hire any QA because programmers should test their own code
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
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
Always choose the coolest software tools that are incompatible with what you want to use them for
Blame everything on programmers including hardware and networking failures, for added bonus assume all programmers want to put porn on your company’s websites
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
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
Believe the code people talk about is more real than the software you can actually see working
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
Plan learning opportunities for your developers based on suggestions from your lawyers to minimize lawsuits
Design application features based on suggestions from your lawyers to minimize lawsuits
Have competing groups specify architectural choices developers have to use; for best benefit ensure they are incompatible
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
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
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
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
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