Got a project you don't like? Glutton for punishment? Testing human frustration tolerances? Here is our exclusive guide to making sure your work nosedives as inelegantly as possible.
10 - Artificially overdeliver. You have a few choices at your disposal here; cutting quality is great for making sure anyone who needs to touch your system in the future feels the pain of difficult future development, however if it's your current colleagues you want to punish, you just can't go past agreeing to 'wishful thinking' estimates from outside the team and then hiding the true cost of all the epic hours needed to catch up to the unfeasible plan.
9 - Forget about maintenance. After all, what are the chances you'll still be around to live with this (especially after the next 8 steps)? Don't plan for future changes or support requirements, just throw together the functional stuff and kick it out the door. Tomorrow never comes.
8 - Don't share knowledge. Keep away from your teammates. Squirrel away your own documentation in arcane formats known only to yourself. Be especially careful not to volunteer information at meetings or conform to any build or code conventions. This way you minimise the risk of learning something from someone else or helping someone to be a better engineer.
7 - Shave as many yaks as you can. If you can see a complicated, expensive way to do something then that's got to be the best way forward. Trying to meet the intricate web of dependencies will also keep everyone else too busy to notice you cleverly stacking your CV with unnecessary, esoteric technology.
6 - Never question requirements. Everyone in every business knows exactly what they want all the time and they never need any help to articulate it in a way developers can use. Furthermore, because everyone is a technology expert, don't worry about receiving requirements that describe solutions instead of problems; it's bound to be the right way to meet the business need so just roll with it. Keep it all printed out too, because when you ship your product and the stakeholders say it isn't really what they had in mind, you can deliver the coup de grace to the relationship by waving it around at them. Oh and whatever you do, make sure you don't get to know any of the end users. It would be a little embarrassing if you ended up with a good user experience.
5 - Make everything perfect. You'll probably hear odd noises about vanishing market opportunity, missing SLAs, dependent projects, and publicised launch dates... propaganda! Just keep on refactorbating even the most inconsequential features until no one remembers there was once a deadline.
4 - Computers are indestructible. Not many people know this, but nothing will ever go wrong with your servers or network infrastructure. Ergo, you can forget about failure conditions as coding and testing for failure modes is just a waste of good refactorbating days. Same goes for NFRs.
3 - Don't establish priorities. Going right back to the dawn of time there has never been a single recorded case of a project not being able to deliver 100% of it's original scope within its original timeframe. So why bother prioritising work? It's not like you'll never need the information...
2 - Test last. The earlier in the lifecycle you can fix bugs the cheaper they are to find and resolve. That almost sounds like a successful strategy, so we'd best leave them as late as possible (bonus points for post-live).
1 - Never look back. Topping the charts at number 1 is the single most important practice for ensuring a long and painful career in making a dogs breakfast out of any project; ignore the past. Don't do any retrospectives and you'll never be in danger of accidentally learning from past mistakes and improving future iterations.
There are dozens more ways to ensure poor results and a distinct lack of job satisfaction, set your sights on failure by starting off with these 10.
Subscribe to:
Post Comments (Atom)
Posts
0 comments:
Post a Comment