Editing Talk:2730: Code Lifespan

<!--Please sign your posts with ~~~~ and don't delete this text. New comments should be added at the bottom.-->
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. 
<br />My own experience is that one loses the fun of programming something if the perfectionism plays to big of a role.{{unsigned ip|162.158.203.40|14:53, 27 January 2023}}‎
: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!) [[Special:Contributions/172.70.86.28|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. -- [[User:Hkmaly|Hkmaly]] ([[User talk: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. [[Special:Contributions/172.70.90.141|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. :) [[User:NiceGuy1|NiceGuy1]] ([[User talk: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.
<br />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.[[Special:Contributions/172.69.68.97|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. [[Special:Contributions/172.71.151.100|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 >.> [[Special:Contributions/172.70.206.150|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 ''n''th 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. [[Special:Contributions/172.71.242.11|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 [[Special:Contributions/172.69.34.112|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. [[Special:Contributions/172.71.242.11|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. [[User:Rtanenbaum|Rtanenbaum]] ([[User talk:Rtanenbaum|talk]]) 18:58, 27 January 2023 (UTC)
Latest revision		Your text
Line 29:		Line 29:

	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. [[User:Rtanenbaum\|Rtanenbaum]] ([[User talk:Rtanenbaum\|talk]]) 18:58, 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. [[User:Rtanenbaum\|Rtanenbaum]] ([[User talk: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.[[User:Xurkitree10\|Xurkitree10]] ([[User talk:Xurkitree10\|talk]]) 16:32, 28 January 2023 (UTC)~~