eXtreme Go Horse Methodology (XGH)

By talking about Agile Marketing, and Agile in general, with a foreign friend, I figured out that people outside Brazil are not familiar with the eXtreme Go Horse Methodology. Even though we’ve seen it applied to many companies (like Tesla), apparently this widely used global methodology was only formally detailed by Brazilian Devs. Here it is:

Disclaimer: This is a satire of badly implemented Agile and programmer behavior. Please don’t go around thinking that this is a real methodology.

Source (Portuguese): http://sou.gohorseprocess.com.br/extreme-go-horse-xgh/

Translation: https://gist.github.com/banaslee/4147370

1. I think, therefore it’s not XGH.

In XGH you don’t think, you do the first thing that comes to your mind. There’s not a second option as the first one is faster.

2. There are 3 ways of solving a problem.

The right way, the wrong way and the XGH way; which is exactly like the wrong one but faster. XGH is faster than any development process you know (see Axiom 14).

3. You’ll always need to do more and more XGH.

For every bug solved using XGH, seven more are created. As all of them will be solved using XGH, then it's utility tends to the infinite.

4. XGH is completely reactive.

Errors only come to exist when someone notices them.

5. In XGH anything goes.

It solves the problem? It compiled? You commit it and don’t think about it anymore.

6. You commit always before updating.

If things go wrong your part will always be correct… and your colleagues will be the ones dealing with the problems.

7. XGH doesn’t have schedules.

Schedules 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 database through some crazy script).

8. Be ready to jump ship or blame someone else when it goes down.

For people using XGH someday the ship goes down, as time passes by and the system grows into a bigger monster. When that day comes, you'd better have your resume ready or have someone else to blame.

9. Be authentic. XGH doesn’t follow patterns.

Write code as you see fit. If it solves the problem, commit and forget about it.

10. There’s no refactoring just rework.

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.

11. XGH is anarchic.

There’s no need for a project manager. There’s no owner and everyone does whatever they want when the problems and requirements appear.

12. Always believe in improvement promises.

Putting TODO comments in the code as a promise that the code will be improved later helps the XGH developer. He/She won’t feel guilt for the shit he/she did. Surely there won’t be any refactoring (see Axiom 10).

13. XGH is absolute.

Delivery dates and costs are absolute things. Quality is 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)

14. XGH is not a fad.

Scrum, XP? Those are just trends. XGH developers don’t follow temporary trends. XGH always was, and always will be used by those who despise quality.

15. XGH is not always WOP (Workaround-oriented programming).

Many WOP require smart thinking. XGH requires no thinking (see Axiom 1).

16. Don’t try to go against the tide.

If your colleagues use XGH and you are the only uptight coward 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.

17. XGH is not dangerous until you see some order in it.

This axiom is very complex but it says that a XGH project is always in chaos. Don’t try to put order into XGH (see Axiom 16) as it’s useless. You’ll spend a lot of precious time and it will make things go down even faster.

Don’t try to manage XGH, because it’s auto-sufficient (see Axiom 11), like chaos.

18. XGH is your bro. But it’s vengeful.

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 uptight system will collapse. When that happens only XGH can save you.

19. If it’s working don’t bother.

Never ever change — or even think of question — a working code. That’s a complete waste of time. Even more as refactoring doesn’t exist (see Axiom 10).

Time is the engine behind XGH and quality is just a meaningless detail.

20. Tests are for pussies.

If you ever work with XGH you'd better know what you’re doing. And if you know what you’re doing, then why test? Tests are a waste of time. If it compiles, it’s good.

21. Be used to the ‘living on the edge’ feeling.

Failure and success are really similar and XGH is not different. People normally think that a project can have greater chances of failing when using XGH. But success is just a way of seeing it.

The project failed. You learned something with it? Then for you it was a success!

22. The problem is only yours when you name is on the code docs.

Never touch a class of code which you’re not the author. When a team member dies, or stays away for too long, it will eventually go down. When that happens use Axiom 8.

— —

Like it? Read my other stories like:

Creativity in The Times of Data — How startups and big companies can benefit from mixing these two worlds?