This story includes a lot of sarcasm and this methodology should not be used for real projects, unless you want to 🙃. That Brazilians are famous for their awesome sense of humor, memes, and trolling over the internet, we are well aware of, but what you might not know is that we have our own software development process called eXtreme Go Horse (we will be using XGH for short). It’s of course, more a meme than an actual process, but what you might not know is that you might be applying some of the XGH rules to your development process and building a not-so-reliable piece of software. eXtreme Go Horse Rules These rules were freely translated from the not-so-official . XGH website 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 no second option as the first one is faster. 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). You'll always need to do more and more XGH. For every solved problem using XGH 7 more are created. And all of them will be solved using XGH. Therefore XGH tends to the infinite. XGH is completely reactive. Errors only come to exist when they appear. In XGH anything goes. Does it solve the problem? It compiled? You commit and don't think about it anymore. You always commit before updating. If things go wrong your part will always be correct... and your colleagues will be the ones dealing with the problems. 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 DB through some crazy script). Be ready to jump off when the boat starts sinking. Or blame someone else. For people using XGH someday the boat sinks. As time passes by the system grows into a bigger monster. You better have your resume ready for when the thing comes down. Or have someone else to blame. Be authentic. XGH doesn't follow patterns. Write code as you may want. If it solves the problem you must commit and forget about it. 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. 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. 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. Sure there won't be no refactoring (see Axiom 10). 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! XGH is not a fad. Scrum, XP? Those are just trends. XGH developers don't follow temporary trends. XGH will always be used by those who despise quality. XGH is not always WOP (Workaround-oriented programming). Many WOP requires smart thinking. XGH requires no thinking (see Axiom 1). Don't try to row against the tide. If your colleagues use XGH and you are the only sissy 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. XGH is not dangerous until you see some order in it. This axiom is very complex but suggests that an XGH project is always in chaos. Don't try to put an order into XGH (see Axiom 16). It's useless and you'll spend a lot of precious time. This will make things go down even faster. Don't try to manage XGH as it's auto-sufficient (see Axiom 11) as it's also chaos. 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 sissy system will collapse. When that happens only XGH can save you. If it's working don't bother. Never ever change - or even think of questioning - a working code. That's a complete waste of time even more because refactoring doesn't exist (see Axiom 10). Time is the engine behind XGH and quality is just a meaningless detail. Tests are for pussies. If you ever worked with XGH you better know what you're doing. And if you know what you're doing why test then? Tests are a waste of time. If it compiles it's good. Be used to the 'living on the edge' feeling. Failure and success are really similar and XGH is not different. People normally think a project can have a greater chance of failing when using XGH. But success is just a way of seeing it. The project failed. Did you learn something from it? Then for you, it was a success! The problem is only yours when your name is on the code docs. Never touch a class of code in which you're not the author. When a team member dies or stays away for too long the thing will go down. When that happens use Axiom 8. The (un)Official Certification As you might have wondered, if it is a development process like Scrum, it should also have a … well, it does. certification In order to be approved, you have to answer a set of multiple-choice questions on how to develop the right… I mean, the XGH way, and at the end you get a shiny certification, that you should keep away from your LinkedIn if you want to get a job. Unfortunately, at the moment this story is being written, it’s only available in Portuguese, maybe in the future we can take the exam in more languages so all the XGH practitioners around the world can display their certification with pride. But What About Merch? Since the eXtreme Go Horse process have a huge cult of followers, it also has a bunch of merch, ranging from mugs all the way to clothing. So if you want to buy a nice gift for your fellow XFG practitioner colleague for Secret Santa, or just show your love for that incredible methodology, you will not be out of options. I’m not gonna be listing any of the websites that are selling them because it’s faster not to list them, see Axiom 1. I’m Using XGH at My Company, What Should I Do? Keep on the lookout to see more not-so-good development stories, tips, and tricks 🙃

This piece was written for humor or satire and may include nonfactual statements, stories, or anecdotes.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

You Might Be Using eXtreme Go Horse Process and Not Even Know It

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Command and Control Frameworks in a Nutshell

10 Reasons Why Less Is More in Your init/deinit Methods

10 Best Practices for Using Kubernetes Network Policies

10 Best Practices for Every React Developer

12 Essential Coding Standards for Quality Web Development

12 Essential Django Programming Tips for Developers

Command and Control Frameworks in a Nutshell

10 Reasons Why Less Is More in Your init/deinit Methods

10 Best Practices for Using Kubernetes Network Policies

10 Best Practices for Every React Developer

12 Essential Coding Standards for Quality Web Development

12 Essential Django Programming Tips for Developers

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps