Good Code
Good Code
[The comic is a flowchart In order to explain this in text, follow the line numbers. Options follow on new lines without numbers.] How to write good code. [10.] Start Project. [Go to 20.]
[20.] Do things right or do them fast? Fast [Go to 30.] Right [Go to 40.]
[30.] Code fast. [Go to 35.]
[35.] Does it work yet? No [Go to 30.] Almost, but it's become a mass of kludges and spaghetti code. [Go to 50.]
[40.] Code well. [Go to 45.]
[45.] Are you done yet? No. [Go to 40.] No, and the requirements have changed. [Go to 50.]
[50.] Throw it all out and start over. [Go to 10.]
[60.] ? [Go to 70.]
[70.] Good code.

The comic references the common meme of programmers that one can't actually write good code. Either the code is done quickly with shoddy "code style", weak logical structure, or any number of other kludges and hacks which turn maintenance of the code into a nightmare; or else it is written well and beautifully structured, but can never be completed before changes in the situation cause the original code design to be insufficient for one or multiple reasons.
Either situation eventually leads to the need to completely start from scratch, designing and writing the program's code all over again. Of course, the writing of this new program is also locked in the perpetual cycle of choosing between ugly/bad code that works marginally well, or good/pretty code that never gets completed before being obsolete.
Additionally, the humorous point is being further emphasized for the primary target audience, programmers, by using an infinite loop - or more precisely, 2 possible loops and 1 forced loop in the flowchart itself.
Also, of particular note, is the fact that Randall (the author) drives home the point of the inescapability of the infinite loop(s) by the use of the additional, disconnected, and logically unreachable portion of the flowchart. This disconnect points out that the only way to actually get to "Good Code" using the flow chart would be to follow a path of actions — which does not start at the prescribed place — for which there is only an unknown and possibly unknowable starting action which no one has ever discovered previously. Other flowchart comics, several of which are also infinite loops, can be found here .
The title text, "You can either hang out in the Android Loop or the HURD loop," makes a dig at both communities: claiming that Android developers always opt for fast, ugly code, necessitating frequent fixes and updates, while Hurd developers perennially choose to "do the job right" but can therefore never seem to finish their project.
The GNU Hurd Project aims to create the kernel for the GNU Operating System (the kernel being the central and most indispensable component). The GNU Project is most famous these days as a result of GNU/Linux (commonly called just "Linux"), which is an operating system that uses the Linux kernel with the GNU system environment. From the beginning the GNU Project has planned to design their own kernel, the Hurd , virtually from scratch, and given a relatively clean slate with which to work, elected to employ a number of promising and theoretically elegant design concepts . Despite or, as Randall suggests, because of this, the Hurd has been mired in development hell for many years (for decades, in fact) with little progress towards actual usability outside of a small community of kernel hackers. While runnable GNU/Hurd operating systems do exist, they're still basically experimental, and the Hurd remains a collection of research software the design goalposts for which keep receding as other, more pragmatically-engineered technologies continue to be developed (the Linux kernel itself being the canonical first instance of this).
Finally, the official transcript of this comic is itself somewhat humorous (an additional inside joke , if you will) in that it converts the flowchart into a simple list of instructions (aka pseudo-code) using numbered lines as reference points for identifying which instruction to read and follow next. This process is basically identical to the oft-maligned programming technique of using so-called " goto loops ." — Furthermore, there is also a slight cross-reference between infinite loops and goto loops which is probably being referenced, in that goto loops are often criticized (whether accurately or not) as being more likely to create unintended infinite loops in code... primarily because of the difficulty inherent in keeping track of possible entry and exit paths, especially when making edits to the code at a later time.
[The comic is a flowchart In order to explain this in text, follow the line numbers. Options follow on new lines without numbers.] How to write good code. [10.] Start Project. [Go to 20.]
[20.] Do things right or do them fast? Fast [Go to 30.] Right [Go to 40.]
[30.] Code fast. [Go to 35.]
[35.] Does it work yet? No [Go to 30.] Almost, but it's become a mass of kludges and spaghetti code. [Go to 50.]
[40.] Code well. [Go to 45.]
[45.] Are you done yet? No. [Go to 40.] No, and the requirements have changed. [Go to 50.]
[50.] Throw it all out and start over. [Go to 10.]
[60.] ? [Go to 70.]
[70.] Good code.
