Code Lifespan
Surely (no one/everyone) will (recognize how flexible and useful this architecture is/spend a huge amount of effort painstakingly preserving and updating this garbage I wrote in 20 minutes)
Surely (no one/everyone) will (recognize how flexible and useful this architecture is/spend a huge amount of effort painstakingly preserving and updating this garbage I wrote in 20 minutes)
This comic contrasts two scenarios involving Ponytail writing a computer program: in the first panel, she has taken great care to future-proof her code, while in the second, she decides not to under the assumption it will soon be deprecated and/or replaced. The captions below each panel note that, ironically, code that was written with future-proofing in mind will often quickly cease to be used, defeating the purpose of future-proofing, while the code that was not will often be used much longer than the original programmer(s) intended. This is a Catch-22 situation that many developers have experienced; the first one even has a name, YAGNI.
The second panel could be an allusion to the Year 2000 problem, although it is important to note that problem was not simply due to developers not thinking ahead but also because the developers were working with extremely limited computer resources at the time, promoting the use of 2-digit years.
The title text is a modular sentence with two parentheticals, each containing two alternative phrases. This allows for four permutations of the sentence, each of which may be said by programmers. The following two permutations may be the hoped-for ideals of software developers:
- "Surely everyone will recognize how flexible and useful this architecture is."
- "Surely no one will spend a huge amount of effort painstakingly preserving and updating this garbage I wrote in 20 minutes."
However, reality often falls short of such hopes, in that insufficient numbers of people recognize code intended for re-use, and far more people than intended will attempt to maintain and adapt sloppy work. The former can occur because of uncertain or unclear assumptions which aren't clear when the time comes to re-use code capable of it, and the latter sometimes happens because the corner-cutting peculiarities of hasty work are often seen as far deeper necessities than they actually are. The remaining two permutations express these far less hopeful outlooks:
- "Surely no one will recognize how flexible and useful this architecture is."
- "Surely everyone will spend a huge amount of effort painstakingly preserving and updating this garbage I wrote in 20 minutes."