2730: Code Lifespan

|< < Prev Comic #2730 (January 27, 2023) Next > >|

Code Lifespan

Title text: 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)

Explanation

This explanation may be incomplete or incorrect: Created by a BOT PROGRAMMED 50 YEARS AGO. Do NOT delete this tag too soon. If you can address this issue, please edit the page! Thanks.

In the first panel, Ponytail painstakingly future-proofed her code, but all in vain, as it will never be reused again. In the second panel, she decided that future-proofing would be unnecessary, as she assumes nobody would reuse her code that far in the future anyway. This is a Catch-22 situation that many developers have experienced, the first one even has a name, YAGNI. The most famous example of the second panel would be the Year 2000 problem.

The title text proposes four permutations of sentences that software developers may consider, which given the context of the comic, usually start out as these two hoped-for ideals:

• Surely everyone will recognize how flexible and useful this architecture is. And,
• 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 latter sometimes happens because the corner-cutting peculiarities of hasty work are often seen as far deeper necessities than they actually are. As such, the careful reading of the diametrically opposite opinions makes for two far less hopeful statements of:

• Surely no one will recognize how flexible and useful this architecture is. And,
• Surely everyone will spend a huge amount of effort painstakingly preserving and updating this garbage I wrote in 20 minutes.

Transcript

This transcript is incomplete. Please help editing it! Thanks.

[Two situations are depicted between Ponytail and Cueball.]

[Ponytail standing next to Cueball, with her palm raised.]

Ponytail: It took some extra work to build, but now we'll be able to use it for all our future projects.

[Caption below the panel:]

How to ensure your code is never reused

[Nearly identical situation to the first, but with the arm raised slightly less emphatically.]

Ponytail: Let's not overthink it; if this code is still in use that far in the future, we'll have bigger problems.

[Caption below the panel:]

How to ensure your code lives forever

 add a comment! ⋅  add a topic (use sparingly)! ⋅  refresh comments!

Discussion

I'm not sure if the thesis in this comic is accurate. But if it is, my explanation would be that a person with a more spontaneous live-in-the-moment attitude might program stuff that is more interesting, than the stuff made by the person who is (maybe neurotically) obsessed with making clean code.
My own experience is that one loses the fun of programming something if the perfectionism plays to big of a role. 162.158.203.40 (talk) 14:53, 27 January 2023 (please sign your comments with ~~~~)‎

The advice always given to me is "never let the perfect be the enemy of the good enough". Though I tend to bounce between being so obsessive, that I don't realise that I'm now gilding the lilly, or hastily kludging it because of the need for an immediate workaround, knowing that if it needs looking at again then I'll be doing it later anyway and that's when I'll get my gilding gear ready. (Hence why I'm 'always' being told that phrase. But I suspect that there really is no sweet spot between too little and too much, or at least no single keystroke at which I would earn universal praise for my finely balanced tenacity and moderation upon the handling of the issue. Always critics!) 172.70.86.28 17:19, 27 January 2023 (UTC)

Surely there is a sweet spot in the middle where you obsessively spent too much time trying to make the code better and yet it's still so bad you will need to replace it next time. -- Hkmaly (talk) 01:20, 29 January 2023 (UTC)

I'd term it a "sour spot" (or a range, imagined as saddle strung between two peaks of localised idealism, on the n-dimensional continuum of all possible results), but definitely. 172.70.90.141 09:16, 29 January 2023 (UTC)

On the contrary, there are perfectionists like myself who get a distinct satisfaction out of tweaking code to perfection, making it airtight, cover all conceivable bases. Make the code look clean, efficient, making sure it's fully commented... A lot of the joy in programming, for me, comes from this crap. :) NiceGuy1 (talk) 05:25, 28 January 2023 (UTC)

At least at a corporate level, I suspect this phenomenon has an extremely simple explanation. When your code is high-quality, people often won't even realize they are using and interacting with it, because it just does what it's supposed to. When your code is hackish, you and your coworkers will constantly find it breaking seemingly unrelated stuff, forcing them to go back to it over and over, trying to make it work, only to discover it breaks even more things when they try to fix it.
Your high-quality code is still interacting with those seemingly unrelated things, it's simply not breaking the unrelated things, so you don't notice it's interacting with the seemingly unrelated things.172.69.68.97 16:32, 27 January 2023 (UTC)

This also reminds me of 2347: Dependency where a single project made in 1990 has become the backbone of so many other applications. 172.71.151.100 17:47, 27 January 2023 (UTC)

I won't do the edit myself (because I'm shy), but here is how the comic rings to me (from my own current experience): - Often in dev, there are many daily repetitive tasks that are annoying (i.e., build-test-lint-commit-push). These get automated out of spite by someone in a quick'n'dirty way, just to make life easier. It has a limited audience (the development team), but lives on forever, since it is used daily (and therefore maintained accordingly). - On the other hand, the stuff the team codes and sells is subject to changing requirements (cf. next release, marketing, ...). So it gets overhauled often, all the more easily because developers are not familiar with it (because they don't use it, and they worked on some other part of the project). There is also the fact that there is no budget for making changes on the tools, as opposed to the product, so no one really has time to refactor the former - that's how it lives so long! ~~Aveheuzed~~

The never ending war between "I don't have the time to do this right", and "this is way too complex for our simple needs" is exactly where this comic lives. The reality of programming is that general solutions are great for saving time writing, but are often bloated (with unneeded options), miss edge cases, or introduce extra dependencies and slow downs. plus the whole "not invented here" thing coupled with licensing headaches means this will probably still be a thing in a hundred years. PS I think the person explaining missed the point of the order in which the title text options are presented >.> 172.70.206.150 18:19, 27 January 2023 (UTC)

I took the (un)crossed combination as implicit, myself, as I read that version, dealt with prosaically in the follow-up paragraph, but I added the contrariwise statements (and preamble) to the end to make it perhaps more obvious as to the intended humour.

...on your earlier point, add "...I don't have time not to write it as a behemoth of a function, when I'm sure it could all boil down into a few lines that are far simple to understand and maintain". By incremental testing and putting together, you miss that you end up with something that basically has some common role such as "looks for the third non-digit character after every other colon, and returns the first full whitespace-delimitered word that follows on from that" in multiple different data-unmunging instances that all looked the right way to pick apart the necessary data at the time. With time, you can realise that this'ld go nicely into a singly-defined internal function which can be more easily commented, centrally maintained for immediate cross-code consistency, updated or even made more flexible by additional parameterisation (for when it occasionally needs to be the nth non-digit character, etc) and... most importantly... give it a decent function name that does most of the work of commenting its own purpose wherever it appears. But that may takes time, and then they change the stream-format to some alternative that requires a new rewrite across the board. 172.71.242.11 19:05, 27 January 2023 (UTC)

There's definitely space between those extremes. I can't count the number of times I've taken some code and either stripped parts out that were outside my use case, built up something that was missing for the same, or sometimes both at the same time... as long as an eye is kept on internal consistency and a bit of flexibility it usually works out... usually 172.69.34.112 17:02, 28 January 2023 (UTC)

I took it to mean if you say it's fine it isn't (thinking of Murphy and that it's fine fire cartoon here) and if you worry that it isn't it will usually be. Jinx. That's the word I was looking for.18:40, 27 January 2023 (UTC)

"Tempting fate", I'd say, in the latter case. Whatever the overcautious opposite is in the former, which I'm sure has a phrase but I can't immediately think of one so I haven't added the one I know, unpaired. I think we are all having similar thoughts about the philosophical paradoxities, however. 172.71.242.11 19:05, 27 January 2023 (UTC)

Circa 1969, "Surely 16 bits will be enough for a timestamp, it won't break until the year 2000. Who knows if it will still be around by then." Circa 1998, "Surely 32 bits will be enough for a timestamp, it won't break until the year 2038. Who knows if it will still be around by then." But to be fair, while Unix has outlasted one of it's major contributors (Dennis Ritchie, RIP), it was designed with best practices to encourage reuse. Rtanenbaum (talk) 18:58, 27 January 2023 (UTC)

Should this be added to the Code Quality series? It fits the vibe and the title style too.Xurkitree10 (talk) 16:32, 28 January 2023 (UTC)