Basic Rules of Development

1. Never write project plans or design documents. Any kind of blueprinting is for newbies. Large systems can be designed as the code is written.
   
2. If you do have any documents (design or API) related to the code, make sure that the information in one conflicts with the information in another.
   
3. Always comment the obvious (like include statements), but NEVER comment things like business logic, no matter how complicated the code is.
4. Use GLOBAL variables. Make sure to bury the original definition under a couple layers of include statements. Use vague or similar sounding variable names.
5. Pass data to functions using GLOBAL variables.
6. Use as much procedural code as possible.
   
7. Functions are evil.
8. Object-oriented code will cause the sun to explode.
9. Avoid sessions at all costs. We don't understand how they work, therefore, don't use them.
10. Nest as many IF statements as possible. Never use SWITCH/CASE statements or ELSEIF.
11. Load the entire contents of large database tables into arrays, even if you only need one field. Try to do this more than once.
    
12. Reference array key names using another array.
    
13. Store data in array key names and set the data value to a dummy value. Use loops and text statements to extract the data from the key later.
14. Always wrap HTML in print statements. Don't use single quotes, because then you will miss the opportunity to escape all the double-quotes used in HTML attributes.
15. Use inline variables with PRINTF statements.
16. Wrap database statements in as much code as possible. Make sure you perform as many PREG expressions as you can to pseudo-analyze every single SQL statement before actually executing it.
17. Never use SQL join statements, do the joins manually using arrays.
18. Never use bulk copying in SQL. It is better to read an entire database table into an array and reinsert the data into the new table one row at a time.
19. Use inline styling in your HTML with inline variables. CSS is evil.
20. Never unset variables, especially large arrays, even though they may consume 1GB of RAM.
21. Lock/semaphore files and hourly "cp" statements are acceptable substitutes for backups and revision control systems.
22. Never mount your database files on the local file system. Make sure you store them on a network drive that is at least 4 hops away. The more hops, the better.
23. Never use table locking and make sure to use real-time re-indexing on every operation.
24. When you run out of disk space for your databases, have your developers re-engineer the entire program rather than ask the sys admin for more disk space.
25. Never use proper backup systems that can perform incremental backups, compression, or checksums. Full, uncompressed backups using 'cp' are sufficient. Make sure these backups are stored on the same system as the source.
26. If you run out of backup space, have your developers investigate the backups to determine which ones to keep and which ones to delete.
27. Make sure you use outdated comment styling. Use the excuse that your editor can't handle C-style comments (even if it can).
28. Remember that outdated code formatting is what makes an application easy to understand and read, not the actual code, lack of comments, or non-existent design document.
29. Store your field values in a single field such as description so that you have to parse a string to get to them and hardcode values rather than using the actual columns in the database to store the fields.
30. Do as much of your data validation as possible on the client-side and not server-side, because server-side is easy for the user to tamper with and client-side is not.
31. Make sure to define every global constant in your web application on every page request
32. Never use class constants, instead define everything that only your class cares about as a global constant just in case someone else's code changes at runtime and needs that value
33. Always define every literal value as a global constant even if it's only ever used in one function, will never ever change, and could be made clear with a simple comment. The runtime cost of redefining the constant on every request is WELL worth the substantial benefits you're gaining on that line of code
34. Put in dummy variable declarations so your "syntax" checker program won't complain that you only used a global variable once (even though it is defined in another file).
35. Don't use unset. Rather, overwrite the variable _ (underscore), which is a magic, undocumented blackhole.
36. More code means a better product, so never ever use 5 lines of when 10 lines will do.