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 first thing is to get the common misconceptions out of the way.
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.
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.
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.
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.
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.
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).
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”)
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).
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.
Errors only exist when they surface.
Solved the problem? Compiled? Commit and that’s it.
If shit happens, your part will always be correct... and your colleagues can go fuck themselves.
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).
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.
Write the code however you want, if it solves the problem, commit and that's it.
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).
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).
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).
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!
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.
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”.
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.
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.
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.
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.
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.
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!
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.
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!
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).
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.