Re:IRS’ 60-Year-Old IT System Failed on Tax Day Due to New H...
by favorited on Monday April 30, 2018 @03:12PM
(#16961338)
But it's not something that was written once and has been used as-is for 40 years – it has constantly changed to match the tax code. The IRS has claimed that it is difficult for them to find engineers who can maintain it. After all, they didn't start a major project to port it to Java for no reason.
I also disagree with Mayer's assertions about LOC. In my professional experience, the best ways to avoid bugs are optimizing for clarity as well as continuously grooming your codebase (including modernizing when possible). Obviously the latter is not an option for safety-critical software, and probably not suitable for the tax system either. But in general, those practices have worked better for me than have others.
Re:IRS’ 60-Year-Old IT System Failed on Tax Day Due to New H...
by staticfish on Monday April 30, 2018 @04:38PM
(#16962088)
> <snip> if there were any obvious bugs they would have been found by now.
Really, that's what they said about CPUs - at least if you're not in the fab industry.
Why is that scary? It has decades of real life testing applied to it if there were any obvious bugs they would have been found by now.
Assembly is just another language, it is slower to develop in but there are many examples of high level language issues that are at least as scary as what you could do in assembly. In the end it is all about the processes around your development as much or more than it is about what language you pick. The best way to reduce your chance of bugs is to reduce the size of your project.
https://www.mayerdan.com/ruby/2012/11/11/bugs-per-line-of-co...