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.

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.

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.

[1] joeduffyblog.com/2016/02/07/the-error-model/#easily-auditable-callsites

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.

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.

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.

They would be long gone, but available at a high daily contract rate

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.