Anyone else rethinking Social Security timing?

Status
Not open for further replies.
It’s not hard to understand how many large public and private enterprises have fallen so far behind in the systems they deploy - while others stay current. In the case of Soc Sec and other Fed agencies it’s clear Congress has had a role, short term thinking driven by decades of deficit spending, “kicking the can down the road.” Many of the same people who complain about the IRS and Soc Sec also want to further cut the agencies, and then wonder why they don’t get better…

 
Last edited:
Wouldn't age 70 benefit be 116% of age 68 benefit?
Not quite since DRCs accrue from FRA so the difference from 68 to 70 would be an additional 16% of your FRA amount, not 16% added to your age 68 amount. DRCs are not compounded as they accrue.
 
Not quite since DRCs accrue from FRA so the difference from 68 to 70 would be an additional 16% of your FRA amount, not 16% added to your age 68 amount. DRCs are not compounded as they accrue.
Agree... so if FRA was 67 then age 68 benefit would be 108% of PIA and age 70 benefit would be 124% of PIA, so age 70 benefit would be 114.8% of age 68 benefit (124%/108%... not 116%)... plus 2 years of COLAs.

But both would get the same COLA increases. So for example let's say the 2 years of COLAs are 6%... age 68 benefit would be 108%*106% or 114.5... meanwhile, age 70 benefit woud be 124%*106% or 131.4 so same 114.8%.
 
I'd planned on waiting till 70 but got impatient and filed at 69. As in your case, the extra wasn't much, and I figured you never know how it will change in the future.



Remember Y2K? Companies were scrambling to find COBOL programmers to make sure their coding worked after 1/1/2000. I can't imagine taking on a re-write of the SS systems.

Y2K? those people?

Sometime after Y2K I helped on Megacorp's RFP response to update the IRS' s systems. The project was canceled due to funding but the technical debt keeps piling on.

From my memories: Many of the IRS systems were developed in assembly language. Pretty common back then. Some had been updated to COBOL via code conversion utilities. Many of us who knew assembly and COBOL thought the assembly was better. The COBOL was spaghetti code, unreadable for many COBOL jocks and absolutely hated by the assembly crowd.

Some of what wasn't converted contained some amount of self modifying code(yeah it's fun), COBOL supports "alter goto" statements but not much else.

I know AI has been hyped to do away with programmers. IT CAN FIX THIS! It's not a code conversion issue now but a programming paradigm shift to get to a modern OO language.

Sad thing is most developers with assembly and COBOL skills are post retirement age. We're not going back.
 
at that rate, they'd better get going on the Y2.1K problem (2100 is not a leap year but most old programs think it is), only 75 years and 2+ days remain
 
we can always hope the current debt reduction effort will stop so that SS can run out of money before the 2038 problem
 
.... Many of the same people who complain about the IRS and Soc Sec also want to further cut the agencies, and then wonder why they don’t get better…
Often, throwing more people (and/or money) at a problem isn't the best solution. Maybe new ways of doing things, with fewer people and lower costs is the way forward?
 
With certain management folks were keen to get a project done and suggested flooding the zone with more heads/resources I would tell them just because it takes one woman 9 months to make a baby doesn't mean that 9 women can make a baby in a month. :facepalm:
 
at that rate, they'd better get going on the Y2.1K problem (2100 is not a leap year but most old programs think it is), only 75 years and 2+ days remain
Maybe it will be resolved before SS.
 
I can understand why SS and others keep legacy software going. Way back when, no one worried about code longevity. It was simply assumed there'd be better hardware and better software coming while wages remained steady. Demand for software would be limited because few could afford the big iron hardware it needed. Well, we know what changes followed.

Until AI can do most programmning, coding costs will remain high, and old programs will still be used because they are costly to replace. There's some software I created in the '80s that not only remains in use, it's still adding new users, and I get a few $ for each purchase. I suspect AI will kill that off before much longer, but who knows?
 
Often, throwing more people (and/or money) at a problem isn't the best solution. Maybe new ways of doing things, with fewer people and lower costs is the way forward?
What a concept!
 
afraid to say the mucking around has already happened with SS & medicare. neighbor is having multiple issues registering on-line and her calls are not being returned in a timely manner from the local SS office. who knows where this mess will land.
 
Back in my working days, I worked with SSA a few times, and even came onsite to help them as they overhauled their network. I even saw a huge nearly empty room showing how much they were able to efficiently replace. They weren't cutting edge but they weren't behind either. However, this negates nothing said here, because it enabled them to keep the mainframes and programs.
 
Wouldn't age 70 benefit be 116% of age 68 benefit?
True of course. I guess what I meant was the lifetime benefit for 68 vs 70 is much less than 62 vs 70 - for those who don't look at the math.
 
Often, throwing more people (and/or money) at a problem isn't the best solution. Maybe new ways of doing things, with fewer people and lower costs is the way forward?
If you read the link I provided, SS has had modernization plans but they've had a tougher time getting the funds to implement. Might have to spend something to get to better productivity. You can't gut the workforce and leave infrastructure as is and expect performance to improve.
 
Status
Not open for further replies.

Latest posts

Back
Top Bottom