{ "postTitle": "eXtreme Go Horse (XGH)", "timestamp": "1675126863", "editedTimestamp": "1676162686", "postContent": "
    \n
  1. If you needed to think, then it's not XGH.
    2. \n
    \nXGH doesn't think, it does the first thing that comes to mind. There is no second option, the only option is the fastest one.\n

    \n
  2. There are 3 ways to solve a problem: The correct one, the wrong one and the XGH one, which is the same as the wrong one, only faster.
    3. \n
    \nXGH is faster than any software development methodology you know (See Axiom 14).\n

    \n
  3. The more XGH you do, the more you'll need to do.
    4. \n
    \nFor every problem solved using XGH, about 7 more are created. But all of them will be resolved in the XGH way. XGH tends to infinity.\n

    \n
  4. XGH is fully reactive.
    5. \n
    \nMistakes only exist when they are noticed.\n

    \n
  5. With XGH anything goes, except putting your ass on the line.
    6. \n
    \nDid it solve the problem? Did it compile? Commit and that's the end of it.\n

    \n
  6. Always commit things before deploying.
    7. \n
    \nIf shit goes wrong, your commit will always be correct… and your teammates can get fucked.\n

    \n
  7. XGH has no deadline.
    8. \n
    \nThe deadlines sent by your client are mere details. You will ALWAYS be able to implement EVERYTHING in the necessary time (even if it means accessing the production DB through a silly script).\n

    \n
  8. Be prepared to jump out when the ship starts to sink… or place the blame on someone or something.
    9. \n
    \nFor those who use XGH, one day the ship will sink. The more time passes, the more the project becomes a monster. When the castle of card finally falls, your resume better be uploaded to LinkedIn or Indeed, or have someone else to blame.\n

    \n
  9. Be authentic, XGH does not respect standards.
    10. \n
    \nWrite the code as you see fit, if it solves the problem, commit and that's the end of it.\n

    \n
  10. There is no refactoring, only rework.
    11. \n
    \nIf something fails, redo with a quick XGH that solves the problem. The day the rework implies rewriting the entire application, get the fuck out, the ship will sink soon (See Axiom 8).\n

    \n
  11. XGH is totally anarchic.
    12. \n
    \nThe figure of a project manager is completely disposable. It has no owner, each one does what they want when problems and requirements arise (See Axiom 4).\n

    \n
  12. Always deceive yourself with promises of improvements.
    13. \n
    \nPutting TODO in the code as a promise of improvement helps the XGH developer not to feel remorse or guilt for the mess he made. Of course, refactoring will never be done (See Axiom 10).\n

    \n
  13. XGH is absolute, it's not attached to relative things.
    14. \n
    \nTime and cost are absolute, quality is totally relative. Never think about quality, but about the shortest time that the solution will be implemented, in fact… don't think, do it!\n

    \n
  14. XGH is timeless.
    15. \n
    \nScrum, XP… all of these are fads. XGH doesn't stick to the fads of the moment, that's sissy stuff. XGH has always been and always will be used by those who despise quality.\n

    \n
  15. XGH is not always WOP (Workaround Oriented Programming).
    16. \n
    \nMany WOPs require very high reasoning, XGH does not deal with reason (See Axiom 1).\n

    \n
  16. Don't try to row against the tide.
    17. \n
    \nIf your co-workers use XGH to code and you're a do-it-right bourgeois, forget it! For every Design Pattern you use correctly, your peers will generate 10 times more rotten code using XGH.\n

    \n
  17. XGH is not dangerous until some order appears.
    18. \n
    \nThis axiom is very complex, but it suggests that by design using XGH means chaos. Don't try to order XGH (See Axiom 16), it's useless and you can waste precious time. This will cause the project to sink even faster (See Axiom 8). Do not try to manage XGH, it is self sufficient (See Axiom 11), as is chaos.\n

    \n
  18. XGH is your lover, but he is vindictive.
    19. \n
    \nAs long as you want it, XGH will always be on your side. But be careful, don't abandon it. If you start a project using XGH and abandon it to use a fad methodology, you are screwed. XGH does not allow refactoring (see axiom 10), and your new project full of frills will collapse. And at that moment, only XGH can save it.\n

    \n
  19. If it's working, don't touch it again.
    20. \n
    \nNever 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 XGH and quality is a negligible detail.\n

    \n
  20. Testing is for the weak.
    21. \n
    \nIf you've got your hands on an XGH project, you better know what you're doing. And if you know what you're doing, what are you going to test for? Tests are a waste of time, if the code compiles, it's good enough.\n

    \n
  21. Get used to the feeling of imminent failure.
    22. \n
    \nFailure 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 its success. But success and failure are a matter of point of view. Okay, the project went downhill but did you learn anything? Yes? So for you it was a success!\n

    \n
  22. It's only your problem when your name is on the class Doc.\n

    \nNever put your hand on a class whose author is not you. If a team member dies or is sick for too long, the ship will sink! In that case, use Axiom 8.
    23. \n
    \n
\n\nTranslated from Brazilian Portuguese by [@pedrox486](https://pedrocx486.club) with permission from Go Horse Process. \nCheck the original [here](https://gohorseprocess.com.br/extreme-go-horse-xgh/).", "filename": "extreme-go-horse-xgh.json", "draft": false }