eXtreme GO HORSE (XGH) - The New Way of Software Dev

I’m proud to present to you a new way to develop Software.

eXtreme Go Horse

Presented by ” http://sou.gohorseprocess.com.br/ “

1- If you have to think about it, it is not XGH.

XGH doesn’t think, it does the first thing that comes to mind. There is no second option, the only option is quicker.

2- There are 3 ways to solve a problem, the right, the wrong and the XGH, which… is the same as the wrong one, but it’s FASTER.

XGH is faster than any software dev methodology you know.

3- The more you use XGH, the more you’ll have to.

For each problem solved using XGH, another 7 emerge. But they are all solved using XGH. XGH begets XGH to infinity.

4- XGH is totally reactive.

Errors only exist once seen.

5- In XGH everything goes.

Did it solve the problem? Compiled? Then commit it and leave it.

6- Commit always… ALWAYS before update

If it goes wrong, your thing will always be working, your colleagues can fuck themselves.

7- XGH doesn’t know deadlines.

Any deadline given by clients are mere details. You can ALWAYS implement EVERYTHING before the deadline(no matter what you need to do, even if it means accessing the database with a crazy script).

8- Always be prepared to abandon ship when it starts sinking… or put the blame on somebody or something.

For every Go Horser, there is that day. That sad day when the boat sinks. The longer XGH is implemented, the bigger the monster your system becomes. You better be sending curriculums or have somebody to put the blame on.

9- Be yourself, XGH doesn’t respect standards.

Write the code as you wish, be YOURSELF. YOU DO YOU. If it solves the problem, commit it and leave it at that.

10- There is no refactoring, only rework.

If shit goes bust, do a new XGH fast that solves the problem. The day will come when rework will mean rewrite the whole application, when that day comes, see Axiom 8 and be prepared to abandon ship.

11- XGH is totally Anarchic.

The figure of a project manager is…like… totally disposable. There are no owners, everyone does what they want the moment problems and requisites are arising. See Axiom 4.

12- Always delude yourself with promises of making things better later on.

Putting TODO in the code as promise to make said thing better helps the Go Horser not feel remorse or guilt for the shit she/he has done. Of course a refactoring will never be made. See Axiom 10.

13- XGH is absolute, it doesn’t concern itself with relative things.

Deadline and cost is absolute, quality is like… TOOOOtally relative man. Never think of quality but on the least amount of time the solution will be implemented. By the way, don’t think, just DO.

14- XGH is timeless.

Scrum, XP, everything is just the new hype. XGH doesn’t follow fashion, that thing is for front-end developers. XGH has and will always be used by those who despise quality.

15- Don’t swim against the Tide.

If your colleagues use XGH to code, and you are a piece of shit that likes to do things by the book, FORGET IT! For every Design Pattern you use correctly, your colleagues will generate 10 times more rotten code using XGH.

16- XGH isn’t dangerous until Order comes along.

This Axiom is very complex, but assumes that a project implementing XGH is running in an environment of pure and complete CHAOS. Don’t try to put order on XGH(See Axiom 15), it is pointless and you have other things to do anyway. By trying that, you will make the project sink faster. Don’t try to manage XGH, it is self sufficient, just like CHAOS.

17- XGH is your brodah, but it is vengeful.

While you want, XGH will be by your side. But don’t ever let it go. If you start a system using XGH and abandon your buddy to use a fashionable methodology, you are fuuuuucked. XGH doesn’t allow refactoring, and your new system full of willy wolly crapadoodles will collapse. At this time, only XGH will save you.

18- If it’s working, let it be.

Never, EVER, mess about with code that works. That is a waste of time in itself, and adding to that, refactoring doesn’t exist(Axiom 10). Time is of the essence and it is what moves XGH. Quality is a despicable detail .

19- Testing is WEAKNESS.

If you put your hand on a XGH system, you better know what you are doing. And if you know what you are doing, WHY TEST? Tests are a waste of time, if the code compiles, it is enough.

20- Get used to the constant feeling that Failure is imminent.

Failure and Success always walk holding hands, and in XGH it is no different. People use to think that the chances of a project failing using XGH are always greater than it succeeding. But success and failure are a matter of point of view. The project went downhill but you learned something? Then for you it was a Success!

21- The problem is only your when your name is in the Documentation of the class.

Never put your hand in a class which the author isn’t yourself. In case someone in your team dies or is sick for a long time, the boat WILL sink! Be mindful of Axiom 8.