Overview
Manifesto for the most widely adopted Development methodology in the world, now for Factorio.Easy to follow design principles with the fastest results for your Factory, guaranteed.
Introduction
The following guide provides the Factorio-adapted manifesto of the popular Agile development methodology known as Extreme Go Horse (XGH). Being most recognized in the field of Software Development, it is in fact faithfully adopted by pragmatic Engineers of all major fields of study around the world who simply “want to get things done”, coincidentally just in time for Happy Hour.
The manifesto consists of 22 simple and concise Axioms to be followed for breakneck speed design and maintenance of your single/multiplayer Factory. They’re so easy to follow, you may already be an adopter without even knowing about it.
1 – I think, therefore it isn’t XGH.
XGH doesn’t think, it simply does the first thing that comes to mind. There are no other options, as this only one option makes it the fastest.
2 – There are 3 ways to fix a problem. The right way, the wrong way, and the XGH way; which is like the wrong way but faster.
XGH is uncontestedly faster than any development methodology you may have heard about (See Axiom 14).
3 – The more XGH gets used, the more it will be needed.
For each problem solved using XGH, 7 others are created. However, they’ll all be solved with XGH. Therefore, XGH’s usefulness quickly approaches infinity.
4 – XGH is totally reactive.
Errors in your designs only ever exist if they show up.
5 – Anything goes in XGH.
Does it fix the problem? Are things getting where they should? That’s it, move on.
6 – Always plug your design before asking.
If things go wrong elsewhere or get cramped, your part will always be correct. Your colleagues will just have to deal with it.
7 – XGH has no deadlines
Your Research & Development department’s complaints of there not being enough throughput are irrelevant. You’ll always be able to implement everything before Science gets halted, even if this means hauling materials into assemblers manually for a bit.
8 – Be prepared to shift the blame
If you use XGH, the factory will eventually become unsalvageable. The longer it lives on, the more of a monster it will become. When this day comes, be ready to deconstruct it and blame it all on the map seed or even another player as you set out to make another thread on the forums looking for other people to play with.
9 – Be authentic, as XGH does not respect patterns
Make belt, pipe and assembly lines as you see fit. If it fixes the problem, leave it at that.
10 – There is no refactoring, only rework
If things are doing poorly, simply scrape up yet another XGH solution to fix it. The day a rework implies in redesigning the entire factory, it’s better to destroy the entire thing and start over without it.
11 – XGH is totally anarchic.
The idea of discussing a plan or assigning tasks is completely unnecessary. The factory has no owner, everyone can do whatever in however way they want once problems and requirements start trickling in.
12 – Deceive yourself with promises of improvement
Writing “TODO” or “FIXME” in Map markers (M -> Right Click) as a promise of improving an implementation aid the XGH designer in not feeling either remorse or guilt for whatever crap situation they’re eventually responsible for creating. Of course, such refactoring will never happen (see Axiom 10).
13 – XGH is absolute, therefore it is unattached to relativity
Time spent and Science progress are absolute, quality is totally relative. Never think about quality/efficiency but rather the least amount of time with which the solution shall be implemented. Actually, don’t think at all. Simply do it.
14 – XGH is a timeless classic
Train control circuits, megabase designs… those are simply trends. XGH doesn’t stick to trendy, overly specific layouts as it can be employed during any phase of a factory. Ultimately, XGH has always been and will always be used by those who despise quality.
15 – XGH is not a “workaround”
Many workarounds require reasoning and consideration about several other things within a factory. XGH does not reason (see Axiom 1).
16 – Never go against the tide
If your work colleagues use XGH to layout the factory and you want to do everything right and optimal, forget about it. For every design you use efficiently, your colleagues will generate 10 times more rotten layouts using XGH.
17 – XGH is not dangerous until there is some order
This is a very complex axiom, but it suggests that a factory using XGH is by all means balanced in its own chaos. Do not try to make things orderly (see Axiom 16), it is useless and you’ll be trashing precious time. This will cause the factory to stop working even faster (see Axiom 8). Do not try to manage XGH, for it is self-sufficient (see Axiom 11), just like chaos itself.
18 – XGH is your partner, albeit a vengeful one
As long as you wish it to, XGH will always be by your side. Be advised to never abandon it, however. If a factory starts off using XGH and you abandon it for some trendy designs in exchange, you’re done for. XGH does not allow refactoring (see Axiom 10), and your new factory layered with prissy solutions will collapse in itself. And, when this happens, only XGH will be able to save it.
19 – If things are working, do not touch them.
Besides straight upgrades, never modify, or even consider questioning a belt or an assembly line that is working. That’s a complete waste of time, specially since refactoring does not exist (see Axiom 10). Time is the cog that turns XGH and quality is an expendable detail.
20 – Testing railroads is for the weak
If you’re fiddling with an XGH designed factory, you better know what you’re doing. And if you know what you’re doing, why should you test it? If trains are getting where they should, it’s enough.
21 – Adjust yourself to the feeling of imminent failure
Failure and Success go hand in hand, and within XGH it’s no different. People seem to think that the chances of a Factory failing to launch a single rocket using XGH are always greater than it succeeding. However, success and failure depend entirely on perspective. Has your factory gone to hell but you’ve learned a thing or two? Then, for you, it was a great success.
22 – Only worry about problems when it’s your layout
Never touch another designer’s XGH. If its owner stops joining the server for one reason or another, the factory is done for. In this case, see Axiom 8.
Contribute your XGH
