In XGH you don't think, you do the first thing that comes to your mind. There's no second option, only the fastest one.
- The right way;
- The wrong way;
- The XGH way, which is exactly like the wrong one but faster.
XGH is faster than any development process you know (see Axiom 14).
For every problem solved using XGH, ~7 more are created. And all of them will be solved using XGH. Therefore, XGH tends to be infinite.
Errors only come to exist when they appear.
Does it solve the problem? Did it compile? You commit and don't think about it anymore.
If things go wrong your part will always be correct... and your colleagues will be the ones dealing with the problems.
Deadlines given to you by your clients are all but important. You will ALWAYS be able to implement EVERYTHING in time (even if that means accessing the DB through some crazy script).
For people using XGH someday the boat sinks. As time passes by, the probability only increases. You better have your resume ready for when the thing comes down. Or have someone else to blame.
Write code as you may want. If it solves the problem, just commit and forget about it.
If things ever go wrong just use XGH to quickly solve the problem. Whenever the problem requires rewriting the whole software it's time for you to drop off before the whole thing goes down (see Axiom 8).
There's no need for a project manager. There's no owner and everyone does whatever they want when the problems and requirements appear (see Axiom 4).
Putting TODO comments in the code as a promise that the code will be improved later helps the XGH developer.
Nobody will feel guilt for the shit that has been done. Sure there won't be any refactoring (see Axiom 10).
Delivery dates and costs are absolute things. Quality is totally relative. Never think about quality but instead think about the minimum time required to implement a solution. Actually, don't think. Do! (see Axiom 1)
Scrum, XP? Those are just trends. XGH developers don't follow temporary trends. XGH will always be used by those who despise quality.
Many WOP require smart thinking. XGH requires no thinking (see Axiom 1).
If your colleagues use XGH and you are the only sissy who wants to do things the right way then quit it! For any design pattern that you apply correctly, your colleagues will generate 10 times more rotten code using XGH.
This axiom is very complex, but it says that an XGH project is always in chaos. Don't try to put order into XGH (see Axiom 16). It's useless, and you'll spend a lot of precious time. This will make things go down even faster (see Axiom 8). Don't try to manage XGH as it's auto-sufficient (see Axiom 11) as it's also chaos.
While you want it, XGH will always be at your side. But be careful not to abandon him. If you start something using XGH and then turn to some trendy methodology you will be fucked up. XGH doesn't allow refactoring (see Axiom 10) and your new sissy system will collapse. When that happens only XGH can save you.
Never ever change - or even think of a question - a working code. That's a complete waste of time, even more, because refactoring doesn't exist (see Axiom 10). Time is the engine behind XGH and quality is just a meaningless detail.
If you ever worked with XGH you better know what you're doing. And if you know what you're doing why test then? Tests are a waste of time. If it compiles it's good.
Failure and success are really similar and XGH is not different. People normally think that a project can have a greater chance of failing when using XGH. But success is just a way of seeing it. The project failed. Did you learn something from it? Then for you, it was a success!
Never touch a class of code in which you're not the author. When a team member dies or stays away for too long the thing will go down. When that happens use Axiom 8.
With XGH you thrive on code duplication. Code quality is meaningless and there's no time for code reviews or refactoring. Time is of the essence, so copy and paste, quickly!
Translation: banaslee