Posted by mushrooms on Mar 12, 2014 in Main
Design, Coding and Architecture Practices to Ruin Applications
For fun, try these on your next project!
- Avoid using the native session handler and code your own with an interpretive language. Enjoy the race conditions! Add some delays and stuff to compensate.
- Use a file broker to test for directories and files on the fly, instead of establishing a good installation procedure. That way, you can add overhead to every request.
- Use recursion for iteration instead of a simple for loop. This is especially fun if you are handling huge amounts of data.
- Avoid using position:relative and use float to place elements on the page. Have fun with overflows and difficult displays.
- Add lots of code that copies data between objects and arrays. Don't bother using the database interface as intended by the framework.
- If you don't like other people's code, be sure to just rewrite it. Yours is undoubtedly better.
- Place huge open source libraries and frameworks in the version control system to ensure it's really slow to commit code.
- Never check the error logs. After all, no one else can see them, why should you bother?
- Never check the access logs for performance. You can get all the information you need from Google Analytics! (not)
- Be sure to make things as complicated as possible. Not because it's necessary, but so people will think you are smart. When others have difficulty with your code, blame them.
- Just because performance is really bad and there are 600 second request timeouts, don't worry. The architecture is fine. Lease a bigger server.
- Transaction safety isn't important, if two people are editing the same data element at the same time, the last one to hit save wins!
- More data is good. Dream up lots of ways to end up with lots of bits and bytes. NEVER delete anything, even if it is no longer relevant. DO NOT consider any sort of archive. MySQL can handle it.
- Even though you have SVN, don't delete deprecated functions. Comment them out, or just don't call them. You never know when you might want to use them again. Parsing hundreds of lines of unused code is good exercise for the server.
- Don't delete unused files either. It makes it more fun for other people to guess which files are in use.
- If the components you are relying on are at end of life, don't worry. Don't even consider looking forward to new technologies.
- Chain function calls because it looks cool. Even if you call the same function eight times, chain it instead of using a variable, because it looks cool.
- Blame your predecessors or a lack of time for crappy code. Don't change it. Lament that it is crufty or crusty and that's just too bad. Add some comments in the code to let everyone know the code is bad. Don't even consider changing it. Ever.
- Copy/Paste is an excellent coding strategy. It saves a lot of typing and even more thought. Use it liberally.
- Hurry. Remember it is more important to do something quickly than properly. That's why no one lets you repair the brakes on their cars - they would all end up in a ditch. Or worse.
- Break tasks down to about an hour. That way, developers can spend more time creating and reporting status than writing code. You'll have nice detailed information. It will be random.
- Don't worry that your users may be frustrated by poor performance. It may be really bad, but it's better than it used to be, so it's okay.
- Lay the pages out so that people can't do most operations without scrolling.
- Be suspicious of code you don't understand.
- Use your excellent vocabulary to pontificate, it impresses everyone.
- Nesting is good. If you can created something nested 15 layers deep you are good.
- Abstraction and complexity are much more important than performance. After all, YOU see the code. The clients only see the stuff in the browser.
- If you spent a lot of time working on it, it is sacred. Never admit that the code you wrote could be replaced.
- Set the memory to 6GB on a 15GB machine. Blame PHP for poor memory management. Don't look at your code.
- Swap space is for other people. You won't need it.
- Reusing code is bad. It's better to have three or four different versions of the same thing. That way, you can tinker with them. Don't forget to copy the updates. Or not.
- Randomly choose new technologies to add in to the application. Don't bother checking to see if it fits well. Blame someone else if there are problems.
- Recompile PHP instead of using existing RPMs, even though you're not changing it. You'll look smarter.
- Even if the application is already corrupted with inconsistency, don't let anyone else stray and produce code that performs well but doesn't match the architecture.
- Call it OO. Even if it isn't. You can write procedural code that runs on objects. Write lots.
- Don't check to see if all the files are really required. Deliver them all to the client.
- Just because companies like Microsoft upgrade and change the architecture doesn't mean you should. Plan to run the same code forever. Just add new features.
- Ensure the application can only be deployed one way. If people don't want to do it your way, they can't use your stuff.
- Put all the data in one huge database, even if it is unrelated and causes performance penalties.
- Duplicate data is good. Don't create any shared read only resources.
- If the production server alarms, don't worry about it. After all you're not using it!
- When you get data from the database, be sure to get every possible kibble. Every relationship, every piece. That way, if you want to use it, it's there.
- Avoid efficient batch operations. If you can get a page to render after 2,391 SQL queries you're a special person indeed.
- If the browser is so busy that the animated .gif freezes, add more code and slow down the processing to ensure the .gif does the .gif thing. Don't even consider using a different approach that would provide an animated image while allowing the processing to run as fast as possible.
- Touch everything. If you can change the punctuation on a ticket, do it. Make sure everyone knows how important you are and that you're watching them.
- Validation? Nah.
- You can solve any problem with code from StackOverflow. Use the first post you find, it will usually be perfect.
This entry was posted by elvis and filed under Main.