The Go Horse is a critique of the bad habits of some developers, such as laziness, hacks, not to worry about the operation or security, among others. As the authors are already ending the blog's activities , I'll leave the XGH rules below for you to understand the joke in case the blog goes down someday:
1- Thought, it's not XGH.
XGH doesn't think, it does the first thing that comes to mind. There is no second option, the only option is the fastest one.
2- There are 3 ways to solve a problem, the correct one, the wrong one and the XGH, which is the same as the wrong one, but faster.
XGH is faster than any software development methodology you know (See Axiom 14).
3- The more XGH you do, the more you need to do.
For every problem solved using XGH, another 7 are created. But all of them will be resolved in the XGH way. XGH tends to infinity.
4- XGH is fully reactive.
Errors only exist when they appear.
5- XGH is worth anything, it's just not worth giving the toba.
Solved the problem? Compiled? Commit and that was it.
6- Always commit before update.
If shit goes down, your part will always be correct... and your colleagues be fucked.
7- XGH has no deadline.
The deadlines given by your client are mere details. You will ALWAYS be able to implement EVERYTHING in the necessary time (even if that means accessing the BD through a nasty script).
8- Be prepared to jump off when the boat starts to sink… or blame someone or something.
For those who use XGH, one day the boat sinks. The more time passes, the more the system becomes a monster. The day the house falls, your curriculum better be registered with APInfo, or have something to blame.
9- Be authentic, XGH does not respect standards.
Write the code as you want, if it solves the problem, commit and that's it.
10- There is no refactoring, only rework.
If it sucks, redo a quick XGH that fixes the problem. The day the rework involves rewriting the entire application, jump off, the boat will sink (See Axiom 8).
11- XGH is totally anarchic.
The figure of a project manager is completely disposable. It doesn't have an owner, each one does what they want when the problems and requirements arise (See Axiom 4).
12- Always delude yourself with promises of improvement.
Putting TODO in the code as a promise of improvement helps the XGH developer not feel remorse or guilt for the mess he's made. Of course, refactoring will never be done (See Axiom 10).
13- XGH is absolute, it is not tied to relative things.
Time and cost are absolute, quality is totally relative. Never think about quality, but in the shortest time that the solution will be implemented, in fact… don't think, do it!
14- XGH is timeless.
Scrum, XP… all this is fad. XGH doesn't stick to the fads of the moment, that's fagot stuff. XGH has always been and will always be used by those who despise quality.
15- XGH is not always POG.
Many POG's require very high reasoning, XGH does not reason (See Axiom 1).
16- Do not try to row against the tide.
If your co-workers use XGH to program and you are a coxinha who likes to do the right things, forget it! For every Design Pattern you use correctly, your colleagues will generate 10 times more bad code using XGH.
17- XGH is not dangerous until a little order appears.
This axiom is very complex, but it suggests that the design using XGH is in chaos. Do not try to order in XGH (See Axiom 16), it is useless and you can throw precious time in the trash. This will make the project sink even faster (See Axiom 8). Don't try to manage XGH, it's self-sufficient (See Axiom 11), just like chaos.
18- XGH is your brother, but he's vindictive.
As long as you want, XGH will always be on your side. But be careful, don't leave him. If you start a system using XGH and abandon it to use a fad methodology, you're fucked. XGH does not allow for refactoring (see axiom 10), and your new system full of frescurites will collapse. And at that time, only XGH can save him.
19- If it's working, don't relax your hand.
Never change, let alone question a working code. This is a waste of time, since refactoring does not exist (See Axiom 10). Time is the gear that moves the XGH and quality is a negligible detail.
20- Test is for the weak.
If you've got your hands on an XGH system, you better know what you're doing. And if you know what you're doing, what are you going to test for? Testing is a waste of time, if the code compiles it is enough.
21- Get used to the feeling of impending failure.
Failure and success always go hand in hand, and XGH is no different. People tend to think that the chances of a project failing using XGH are always greater than that it will be successful. But success and failure are a matter of point of view. The project went down the drain but did you learn anything? So for you it was a success!
22- The problem is only yours when your name is in the Doc of the class.
Never get your hand on a class whose author is not you. If a team member dies or is ill for a long time, the boat will sink! In that case, use Axiom 8.
What can we learn from this "methodology"?
Here are some personal observations for this "methodology" that we can take to life:
- Don't be an XGH programmer : don't be the guy who "delivers things on time but doesn't care about quality". Bad code can often look good in the short run, but in the long run it becomes as bad as not doing it;
- Gambiarras are bad, deal with it : don't make gambiarras. Working doesn't mean it's right, it just works. A workaround can have unpredictable side effects, such as generating some kind of garbage, taking up extra memory, generating delays, among others. Just don't;
- Work thinking that others are trying to work too : push before pull, use for
git push --forceno reason, make production updates, and create messy code with no documentation at all are symptoms of a programmer who is sure to be hated by the rest of the team. Do not do this;
- Refactor, refactor, and refactor again : If you see poor code, don't leave it there. Try changing, improving, modularizing, creating automated tests, and so on, just don't let bad code stay bad;
- When you least expect it, you'll have to change the system : changes are inevitable, and that Go Horse function that does email validation, database connection, HTML rendering and email sending deciding when to do each thing using an array passed as parameter is hampering the evolution of the system. You could have avoided this when writing the code;
- When others fail, the hot potato will fall into your lap : project managers DON'T CARE if it was you or your colleague who made that completely indecipherable code that has 200 business rules scattered in a confusing way across the spaghetti you call code, so make sure you and all your colleagues at least program something as decently as possible;
- Use XGH, but in reverse : do you know the axioms of XGH? They are not useless. Read each one of them, and do the exact opposite. Thanks for nothing.