Skip to content

Instantly share code, notes, and snippets.

@lovesegfault

lovesegfault/XGH.md

Last active April 16, 2019 18:25
Show Gist options
  • Save lovesegfault/8a768991e5636b330472 to your computer and use it in GitHub Desktop.
Save lovesegfault/8a768991e5636b330472 to your computer and use it in GitHub Desktop.
Download ZIP
Extreme Go Horse Process
Raw
XGH.md

###Go Horse Process (XGH)

  1. Thought about it? It's not XGH
  • In XGH you don't think, you do the first thing that comes to your head. There's no other option, the only option is the fastest one.
  1. There are 3 ways to solve a problem: the right, the wrong and the XGH way, which is just like the wrong one, but faster.
  • XGH is faster than any other software development methodology you know (See Axiom 14).
  1. The more you do XGH, the more you'll need to do it
  • For each problem solved using XGH seven more are created. But all of them will be solved in the XGH way. XGH tends to infinity.
  1. XGH is absolutely relative.
  • The bugs only exist when they appear.
  1. XGH has no rules, or honor.
  • Solved the bug? Compiled? Commit, and that's that.
  1. Always commit before you update.
  • If it all goes wrong, your part will always be correct, and fuck your colleagues.
  1. XGH has no deadline.
  • The deadlines stablished by your client are but mere details. You'll always be able to implement everything in time (Even if that implies accessing the DB using a sketchy script).
  1. Be prepared to jump off the boat the moment it begins to sink... Or blame something or someone.
  • For an XGH user the ship sinks one day. The more time passes, more the system becomes a monster. When the levee breaks, you better have a LinkedIn profile or be able to blame something.
  1. Be Authentic, XGH doesn't follow standards.
  • Write code as you wish, if it solves the problem, commit and you're done.
  1. There is no refactoring, only rework.
  • If it doesn't work redo an XGH quickly to solve the issue. The day reworking implies rewriting the whole app from scratch, row away, the ship is about to sink (See Axiom 8).
  1. XGH is absolutely anarchic.
  • The idea of a project manager is totally disposable. There's no law, you do what you wish as problems and requirements arise (See Axiom 4).
  1. Fool yourself with promises of improvement.
  • Writing TODO in the code as a promise of improvement helps the XGH developer not to feel remorse or guilt over the shit they've produced. It is clear that the refactoring will never be done (See Axiom 10).
  1. XGH is absolute and doesn't hold itself to relative things.
  • Time and cost are absolute, quality is relative. Never think about quality, but think about less time implementing the solution, actually... don't think, do!
  1. XGH is timeless.
  • Scrum, XP... Those are all but hype. XGH doesn't hold itself to the latest trends, that's for pussies. XGH has always been and always will be used by those who despise quality
  1. XGH isn't always workaround based.
  • A lot of workarounds demand a very refined logic, XGH doesn't think (See Axiom 1).
  1. Don't try to row against the tide.
  • In case your coworkers use XGH to code and you're lame and perfection obcessed, forget about it! For each Desing Pattern you use correctly your coworkers will generate 10 times more shitty code using XGH
  1. XGH is not dangerous until order appears.
  • This is a very complex Axiom, it suggests that a project using XGH is immersed in chaos. Do not try to set order to XGH (See Axiom 16), it's useless and you'll be wasting 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 Axiomm 11), just like chaos.
  1. XGH loves you, but it's also vengeful.
  • XGH will always be on your side while you want it to be. But beware, do not let go of it. If you begin a system using XGH and abandon it halfway to use some trendy methodology you are fucked. XGH does not allow refactoring (See Axiom 10), and your new system full of frills will collapse. In this dark time, only XGH can save you.
  1. If it works, don't sweat it.
  • Never change, and let alone question a working code. It's a waste of time, specially because refactoring isn't a thing (See Axiom 10). Time is the gear that spins XGH, quality is but a despisable detail.
  1. Testing is for pussies.
  • If you're touching an XGH system, you better know what you're doing, and if you know what you're doing, why test? Tests are a waste of time, if the code compiles it's good enough.
  1. Get used to the feeling of imminent failiure
  • Failiure and success always walk side by side, and it's no different in XGH. People tend to think that the chance of the project failing using XGH are always bigger than that of it suceeding. Success and failiure, however, are a matter of perspective. The project went downhill but you learned something? Than for you it was a success!
  1. It's only your problem when your name is on the Class Doc.
  • Never touch a class whose author isn't you. In case a coworker dies or gets sick for a long time, the ship will sink! In this case, use Axiom 8.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment