What is XGH (Extreme Go Horse)?

Question

I see some people in the middle of programming referring to this term whenever a code appears with a strange solution or medium "entwined".

By doing a quick Google search, I’ve come to the conclusion that this really is it.

I found the terms Go Horse Process and Extreme Go Horse.

What I found strange is that in some articles they talk about Go Horse Process, also appeared several topics of "how to do" (22 items) and was even called "methodology".

But what this is really about?

It’s really a methodology, or a joke, or a hilarious way of listing what should be avoided in programming?

Answer 1

The Go Horse or Go Horse Process is a criticism shown in a way to satirize the misuse of certain "methodologies", as well as the "agile methodologies", or no use of them. It is actually a criticism of what many developers often do. Even some with more experience have moments of:

• Laziness/relaxation.
• Do not worry about future corrections or improvements, because they believe that it is definitive.
• Worry about timing, but not about functioning or safety.
• All this usually accompanied by gambiarras.

Understand that the Go Horse (and the andXtrembles Gthe HOrse) is not something to be done, is something that if you will read and will serve to understand that the shouldn’t, as I said before is a criticism of what many developers end up doing.

• Go Horse = going horse
• Go Horse Process = process "go horse"
• Extreme Go Horse = extreme going horse

Horsey has no direct meaning, it probably refers to horse racing.

As mentioned in the other answers, the original site was closed. However, there was a group in Portuguese that was updated and are still active.

The authors Ornado and Mário Marolo left a farewell note http://www.gohorseprocess.com.br/adeus-ou-ate-logo-quem-sabe (with a hint of humor).

Link http://www.gohorseprocess.com.br/extreme-go-horse-(xgh) of the complete list:

1. Thought, it’s not XGH.

   XGH does not think, does the first thing that comes to mind. It does not exist second option, the only option is the fastest.

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, only faster.

   XGH is faster than any methodology of developing software you know (See Axiom 14).

3. The more XGH you do, the more you need to do.

   For each problem solved using XGH, a further 7 are created. But all of them will be solved in the XGH way. XGH tends to infinity.

4. XGH is fully reactive.

   Errors only exist when they appear.

5. XGH is all, just don’t give the ****.

   Solved the problem? Compiled? Commit and that was it.

6. Commit always before update.

   If shit happens, your part will always be right and your colleagues that if *****.

7. XGH has no deadline.

   The deadlines passed by your customer are mere details. You ALWAYS will be able to implement EVERYTHING in time (even if this implies in accessing the BD by a crazy script).

8. Be prepared to jump out when the boat starts to sink... or lay the blame on someone or something.

   For those who use XGH, one day the boat sinks. The more time goes by, the more the system becomes a monster. The day the house falls, its better curriculum be registered at Apinfo, or have something to put the guilt.

9. Be authentic, XGH does not respect standards.

   Write the code as you see fit, if you solve the problem, commit and that was it.

10. No Re-factoring, only rework.

    If it sucks, redo a quick XGH that solves the problem. The day that rework entail in rewriting the whole application, jump out, the boat will sink (See Axiom 8).

11. XGH is totally anarchic.

    The figure of a project manager is totally disposable. There is no owner, each do what you want at the time 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 to feel no remorse or guilt for ****** he did. It’s of course Re-factoring will never be done (see Axiom 10).

13. XGH is absolute, not related.

    Term and cost are absolute, quality is totally relative. Never think about the quality and yes in the shortest time that the solution will be implemented, by the way... don’t think, do!

14. XGH is timeless.

    Scrum, XP... all this is modinha. XGH does not attach to the modinhas of moment, this is ***** * thing. 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. Don’t try to row against the tide.

    In case your coworkers use XGH to program and you are a thigh that likes to do things right, forget it! For each Design Pattern that you use correctly, your colleagues will generate 10 times more rotten code using XGH.

17. The XGH is not dangerous until some order appears.

    This axiom is very complex, but suggests that the design using XGH is in the midst of chaos. Do not try by order in XGH (see Axiom 16), it is useless and you can throw precious time in the trash. This will cause the project sinks even faster (see Axiom 8). Do not try manage the XGH, it is self sufficient (see Axiom 11), as well as the chaos.

18. The XGH is your brother, but he’s vindictive.

    As long as you want, the XGH will always be on your side. But beware, do not abandon it. If you start a system using XGH and abandon it to use a fashionable methodology, you will be *****. XGH does not allows re-factoring (see axiom 10), and its new system full of frescurites will collapse. And at that time, only XGH can save him.

19. If it’s working, don’t touch the hand.

    Never change, let alone question a working code. That’s loss of time, even because Re-factoring does not exist (see Axiom 10). Time is the gear that moves the XGH and quality is a detail despicable.

20. Testing is for the weak.

    If you’ve got your hand on an XGH system, you’d better know what it is making. And if you know what you’re doing, will you test for what? Testing are a waste of time, if the code compiles, it’s enough.

21. Get used to the feeling of impending failure.

    Failure and success always go hand in hand, and in XGH it is not different. People often find that the chances of the project fail using XGH are always greater than he be well succeeded. But success and failure are a matter of point of view. The project went downhill but you learned something? So for you went a success!

22. The problem is only yours when your name is in the class Doc.

    Never lay a hand on a class whose author is not you. If a member of Crew die or get sick for a long time, the boat will sink! In this case, use Axiom 8.

Answer 2

_{So said the Master Programmer: When a program is in the testing phase, it is too late to make scope changes.}

---

Legend has it that in a remote province there was a monastery where the Master Programmer shared his teachings. One of his dialogues was about the practices of the infamous court engineer Xingh, and the events surrounding the construction of the Two Bridges.

---

'Master', discussed one of the architects of the Tang court, 'We begin the work of the North Bridge of the Yellow River following its venerable precepts KISS, YAGNI and DRY, which are the true pillars that support our structure.

But recently the Emperor has been quite impressed with the efficiency of Master Xingh’s team, which apparently ignores all the precepts of the ancient Masters in building the South Bridge - he does not care about balance and harmony, instead reinforcing the structures with whatever is at hand.

Your workers are also treated like slaves - waves of novices come and go, exhausted and disgusted. But still its bridge rises, chaotic to the point where the structure is covered, and its appearance improved. Do you think we’re wasting too much time? We should embrace chaos?'

'Your heart is weak, and your resolve fades with the first breeze,', said the Master Programmer. 'Always seek balance, and always use the pillars of the ancient Masters. Chaos attracts chaos; Harmony attracts harmony.'

The Engineer, embarrassed by the hard but true words, withdrew in silence to the field where the construction team met.

---

The Imperial Court met for the inauguration of the Bridges eight months later.

The North Bridge stood beautiful and delicate; the pride of its artisans, its graceful forms mirrored in the river. Nothing was missing, nothing exceeded it.

The South Bridge, however, had been completed four months earlier - and already had expansions that made it several times wider. Upon meeting the Architect of the North Bridge with the Emperor, Master Xingh could not contain his slender smirk.

The Emperor, a man of numbers, gold and wars, gave tearful praise to Master Xingh for his efficiency. The Crown Prince, an admirer of the Great Masters, thanked the Architect profusely for the new jewel that adorned the city.

The Emperor rode in Jíduān qù mǎ, his favorite horse, and headed for the South Bridge - at the same time that the Crown Prince headed for the North Bridge, mounted on Wěn.

They were all surprised when a roaring noise from the South Bridge, accompanied by a gigantic cloud of dust and wooden barbs, indicated the moment when both the bridge and the Emperor made their way to the river.

"Someone tested if the bridge held horses?" whispered in shock one of the discredited workers of the South Bridge. They looked at each other in silence.

The Prince, who had already crossed the North Bridge, rode fast to the crash site, his tears becoming part of the river upon finding the Emperor’s broken body. At this time the Master Programmer approached the now Prince Regent, and uttered these words:

"May the pain of your loss diminish with time, but never forget the lesson learned here: May KISS, YAGNI and DRY be the pillars of a long and harmonious reign."

---

From that time much is gone and there is no more.

From the South Bridge, only the infamous term 'as a Xingh bridge' remains - and many are unaware of its origin. Nature has taken back the banks of the river, and even its foundation stone has been lost.

But to this day visitors to the Imperial City are welcomed by the North Bridge; countless generations of Emperors have passed under its elegant arches, to which time only added dignity. As haughty as the day of its inauguration, its delicate mirrored forms on the river.

Answer 3

Go Horse is a satire on software development that is basically the joining of people running roles and processes.

The Extreme Go Horse is the methodology that suggests which processes should be executed to achieve the project goals, where practically the only quality metric is "it’s working?".

It is a joke with truth background. Some situations or recommendations even seem strips of Dilbert. It shows that, even with a chaotic environment, no organization, performing equal tasks (repetition) with different results, incompetent people and generation of artifacts that do not add any value. Yes, it is possible to build software that works, meets customer needs and is cost effective.

More acid details in: gohorseprocess

Answer 4

Explaining better. I removed from the Helium site this example.

XGH is one of the most brilliant things that has emerged in recent times, describing the stupidity that applies in agile methods, but that reflects well the corporate environment.

1- Thought, it’s not XGH. XGH does not think, does the first thing that comes to mind. There is no second option, the only option is the fastest.

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, only 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 each problem solved using XGH, a further 7 are created. But all of them will be solved in the XGH way. XGH tends to infinity.

So XGH is a "method" that is widely used today and always. A joke directed at bad methods (POG).

See more in Extreme Go Horse - XGH