Yes, let’s talk a little about being agile and the Brazilian definition of the current state agile generated called “eXtreme Go Horse” methodology.
The misconceptions
The first thing is to get the common misconceptions out of the way.
Agile is going fast
By now, we all (should) know that agile is not about being faster. It’s about delivering value sooner and in a constant manner and being able to react and change course earlier.
Sprint is doing all in the time slot
So… you’re saying agile is not about being fast, but that it also means having… sprints?
It might have been an unfortunate term used by the developers of Scrum, but it certainly doesn’t help with all the “agile is being fast” people like to think.
Sprints, however, are just a time box for a certain amount of work to be done.
The problem
Executives push for agile and scrum because they think about being fast, sprints!
But the biggest problem is that making software is not a sprint, it’s a marathon.
And unless you’re not human, you know that you can’t sprint a marathon. It’s a really bad idea.
Hell! Most people can’t even sprint a short race. And I’m also talking about software.
The people result
Burnout. Plain and simple, the profession loses a lot of good people because of burnout.
Not to be confused with “burndown” (charts), also from scrum, but somehow that doesn't generate any confusion from the same people expecting more and more from developers.
At one point companies had too many developers, many doing basically bloatware features and “not generating enough value”. Then the mass layoffs came and went (or are still going) and now you have developers even more overworked.
The software result
Because people are pressured into going fast and then faster yet, quality drops, and “quick and dirty” becomes the norm.
There’s no time for testing, there’s no time for code quality, or clean code and good practices, but there’s always time and overtime for fixing bugs.
Deliver software not fast, but with consistency
The first thing people see in new frameworks is how fast they can make a “todo app”… but that’s not the reality for most of us.
Go Horsing quick and dirty to make a big bowl of muddy pasta is ok for an MVP, side project, or throw-away project. But most time you’ll be working for months on end on something.
What matters making one thing fast and then slowing down on each new feature until you jump ship (XGH axiom 8) or decide to rewrite the whole thing (see XGH axiom 10).
XGH: eXtreme Go Horse
Go Horse Process logo: a badly drawn horse head inside a circle.
As I was writing this post it came to my attention that XGH is commonly known only by Brazilian devs, but not enough around the world.
This was made by who knows when, by who knows who, it’s a little outdated in the writing (I’ll refactor as needed), but as you’ll see… it’s timeless (see axiom 14) and relevant to what I was saying.
Disclaimer: This is, basically, a “not to do” list. It’s funny as a meme, but as I like to say: if all you do are things from memes… then your life is a joke.
There were some translations out there, but I translated them here trying to update things to make more sense today.
Enjoy but don’t follow it. (little note: people usually just read XGH as “go horse”)
eXtreme “Go Horse” Manifesto:
1. If you had to think, it’s not XGH.
in XGH you don’t think, you do the first thing that comes to mind. There’s no second option, the only option is the fastest one.
2. There are 3 ways of solving a problem: the right, the wrong, and the XGH, which is like the wrong one, but faster.
XGH is faster than any other methodology of software development you know. (see axiom 14).
3. The more XGH you do, the more you’ll need to do.
For each problem solved using XGH, about 7 more will be created. But all of them will be solved using XGH. XGH tends to infinity.
4. XGH is completely reactive.
Errors only exist when they surface.
5. XGH accepts everything.
Solved the problem? Compiled? Commit and that’s it.
6. Always commit before updating.
If shit happens, your part will always be correct... and your colleagues can go fuck themselves.
7. XGH has no deadline.
The deadlines set by your client are mere details. You will ALWAYS be able to implement EVERYTHING in the given time (even if it involves accessing the database with a shady script).
8. Be prepared to jump ship when it starts to sink... or blame someone or something else.
For those who use XGH, one day the ship will sink. The more time passes, the more the system becomes a monster. The day the house falls, it's better to have your LinkedIn updated or have something to blame.
9. Be authentic, XGH does not respect standards.
Write the code however you want, if it solves the problem, commit and that's it.
10. There is no refactoring, only rework.
If shit happens, redo a quick XGH that solves the problem. The day that the rework involves rewriting the entire application, jump ship, the boat will sink (see axiom 8).
11. XGH is completely anarchic.
The figure of a project manager is completely disposable. There is no owner, everyone does what they want when problems and requirements arise (see axiom 4).
12. Always delude yourself with promises of improvement.
Putting TODO in the code as a promise of improvement helps the XGH developer not feel remorse or guilt for the shit they made. Of course, refactoring will never be done (see axiom 10).
13. XGH is absolute, it does not cling to relative things.
Time and cost are absolute, quality is totally relative. Never think about quality, only about the shortest time the solution can be implemented, in fact... don't think, just do it!
14. XGH is timeless.
Scrum, XP... all of that is just a fad. XGH does not cling to the fads of the moment, that's for the weak. XGH has always been and will always be used by those who disregard quality.
15. XGH is not always Workaround-Oriented Programming.
Many Workaround-Oriented Programmings require a very high level of thinking, but XGH does not think (see axiom 1).
Translator Note: In the original, it uses Gambiarra Oriented Programming. Since I understand some people will know what gambiarra is… it’s a more encompassing term than just “hack” or “workaround”.
16. Don't try to swim against the tide.
If your colleagues use XGH for programming and you are a stickler who likes to do things properly, forget it! For each Design Pattern you use correctly, your colleagues will generate 10 times more rotten code using XGH.
17. XGH is not dangerous until a little order arises.
This axiom is very complex, but assumes that the project using XGH is in the midst of chaos. Don't try to add order into XGH (see axiom 16), it's useless and you can waste precious time. This will make the project sink even faster (see axiom 8). Don't try to manage XGH, it is self-sufficient (see axiom 11), just like the chaos.
18. XGH is your ally, but it is vengeful.
As long as you want, XGH will always be on your side. But be careful, don't abandon it. If you start a system using XGH and abandon it to use a trendy methodology, you're fucked. XGH does not allow refactoring (see axiom 10), and your new system full of frills will collapse. And at that time, only XGH can save you.
19. If it's working, don't touch it.
Never change, let alone question, working code. That's a waste of time, especially since refactoring doesn't exist (see axiom 10). Time is the gear that moves XGH and quality is a negligible detail.
20. Testing is for the weak.
If you've put your hands on an XGH system, you better know what you're doing. And if you know what you're doing, why test? Testing is a waste of time, if the code compiles, that's enough.
21. Get used to the feeling of imminent failure.
Failure and success always go hand in hand, and in XGH it's no different. People often think that the chances of a project failing using XGH are always greater than it being successful. But success and failure are a matter of perspective. Did the project go down the drain but you learned something? Then it was a success for you!
22. The problem is only yours when your name is in the git blame.
Never put your hand on a file whose author is not you. If a team member dies or is sick for a long time, the boat will sink! In this case, use axiom 8.
23. More is more.
With XGH, you thrive on code duplication - code quality doesn't matter, and there's no time for abstractions, code reviews, or refactoring. Time is essential, so copy and paste quickly!
24. The code is the documentation.
In XGH, the code is the only documentation needed. Comments and additional documentation are just a waste of time. If someone can’t figure out how the code works, they shouldn’t be working on it (see axiom 20).
25. Security doesn’t matter.
In XGH, security is a secondary detail. It’s a waste of time to implement robust security (see axioms 5 and 7). Trust in luck, in the lack of interest from hackers, and axiom 8.
Top comments (0)