Could you please stop creating accounts for every few comments you post? We ban accounts that do that. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html. Your comments are actually pretty good, but preserving the container is more important, and it's undermined when you use it this way.
HN is a community. You needn't use your real name, of course, but you should have some identity for others to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
I appreciate all you do as a moderator to fend off obvious trolls and griefers. I'm sure it must be a thankless job. However, I feel that your comment is not helpful or constructive. People have legitimate reasons for not wanting to create too long of an online trail so they can remain anonymous. That's okay. If their comments are "actually pretty good" then that's good enough; The user name that's attached is irrelevant. They are contributing value to the site.
Guidelines such as "throwaway accounts are ok for sensitive information, but please don't create accounts routinely" are naive. Non-sensitive information can reveal sensitive things when aggregated. We've all read articles about how anonymized data sets can still contain enough data to identify, or come close to identifying, individuals. I'm sure a number of those articles have been linked to from this web site. Practicing user account rotation is a useful tool for mitigating such risks.
Maybe it's time to rethink this particular site guideline. Let's not throw out the baby with the bathwater when it comes to users making contributions to the site.
They were most likely just kicking the ball down the road either thinking that a more permanent solution will be applied in the 2 decades to come, or just not caring at all because they won't be around in 20 years.
Technical debt tends to accrue this way and many times it's not in bad faith. It's meant as a short term solution to buy some time and ends up being permanent because someone doesn't understand what's the point in spending more money to fix an issue that was "obviously" fixed already.
I wish I could upvote this a few times. I have created so many "just use this for now" solutions that have been in use for more than a decade. The real problem never gets fixed for exactly the reason you stated. "It's working, I don't see a problem" (says the manager) and priorities go to other more burning issues. The debt adds up to thousands of small cuts and and ultimately the sum of the debt becomes very expensive to maintain in terms of hours updating, debugging, getting someone who knows the history, finding old jira issues, etc... I think can-kicking eventually contributes to burn-out.
> "It's working, I don't see a problem" (says the manager) and priorities go to other more burning issues.
Well you know the old saying, save the grease for the squeaky wheels. When you face a major hurdle sometimes the best course of action is to take a shortcut just to avoid it and fix it later when you can properly allocate resource for a solid fix. But most times after the fix it's hard to justify fixing it "again".
I've had managers who said "I understand the issue but we have a budget and more critical cracks to fix", and I've had managers who said "what are you going on about, looks good to me". Result is the same but the potential of each attitude is vastly different. The first kind of manager knows when "that" crack becomes a priority. The second kind of manager is unaware there's a crack.
That's not a problem since you're just going to quickly be rewriting it all using this new language, framework, development methodology, deployment mechanism and infrastructure technology that solves all the old problems so surely it'll fix these problems too.
We can help by preferring and recommending tools which allow for auditability of technical debt.
For example, you can grep a Rust code base for "unwrap", "expect", and "unsafe", while in other languages, ignored return codes or unchecked exceptions are harder to detect.
Similarly, (if I am not mistaken) you can grep Swift code for "try", and find every call site that might throw an exception[1]. Can't do that in Java, C#, or Python!
Tool designers can help by differentiating their products through how well they allow for tracking technical debt.
It's also possible that all the fixes for this were declined by management in the interest of time. If you have a system you can quickly patch suboptimally to get the larger fire lowered, I can see the decision being made to do so. That's clearly irresponsible on management if that choice was made, considering the problem they were dealing with at the time, but if the decision is between "not finishing" and "these few systems still have bugs", I can rationalize it.
It is not irresponsible to use temporary fixes in the face of a hard deadline - what is irresponsible is not going back post-deadline to deal with them with a long-term view. Unfortunately, bonuses typically don't get paid for long-term results...
Even then, is it?
If the choice is between having a major restructuring which results in breaking compatibility and similar once, or kicking the can every 20 years with a minimal patch; I can certainly see the later being the rational decision.
It just so happens that 20 years later both the engineer and the manager have moved on and you find about the patch you needed when your production goes down. And even the corner cutting rarely implies just a "minimal" patch anyway.
Particularly when there is a very hard deadline, as in this case, it is absolutely rational to make it work now and worry about long-term correctness later.
Some of them probably made the assumption that by the time 2020 came around, they would be long gone and it would be somebody else's problem. And they were probably right.
I was in high school in the early aughts. There were a number of stories of my friends Dad's and college aged brothers fixing Y2K bugs.
I remember my best friends older brother saying the same thing. "Well, this isn't a perfect solution, but it will give us about 20 years to figure it out." and then he chuckled quite a bit.
Essentially, my reaction was they got paid to make sure the software avoided breaking, not fixing the core problem. There were so many software programs that were affected, companies didn't have time to completely fix them. Most knew it was just a patch to avoid a major set back financially.
Well, it's not only "I won't be around" but also the fact that such a fixcan be done in a few places easily.
However in many cases such an issue comes from the core data store of the company and then goes into all derived systems. Updating this is a major project, where you need to update all consumers, most likely by adding a whole new API layer isntead of direct data access first and then update all data (don't forget the process to work on the data from the tape archive!) and then move on.
And then comes reality – Y2K has been fixed with hit fixes to the systems which do calculations and then different systems do their work-arounds and then one things "oh, there is this important business change now, but the refactoring has 20 years" and then it's pushed and pushed. Five years later somebody stumbles over the hitfix wonders, asks management, which again pushes other tasks ... and suddenly it's 2020.
Fixing technical debt is often overseen as priorities are on features impacting immediate business value.
For some systems that people who couldn't really do a proper change and the businesses promised they were actually end-of-life, it was a reasonable choice (there were probably bigger fish to fry). 20 years on and it looks like some replacements didn't happen.
If I remember right, there is probably another group 20 more years out that used some date changes to get buy for Y2K. I do hope someone replaces them.
HN is a community. You needn't use your real name, of course, but you should have some identity for others to relate to. Otherwise we may as well have no usernames and no community, and that would be a different kind of forum. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...