4 ms·

The article made no real case for the replacement of the IRS' computers. Sure, there's a case for updating their software, but this isn't the same thing as what

The article made no real case for the replacement of the IRS' computers. Sure, there's a case for updating their software, but this isn't the same thing as what the title says. I think people seem to forget that newer does NOT mean better, and that an old, slow computer which is reliable is infinitely better than a new, fast computer which is either unreliable or idiosyncratic (or both). Contemporary IT seems to have forgotten some wonderful things about mainframes. Most projects to "modernize" working computing systems are just about companies grabbing contract money, and if a proper job happens to get done, it's more or less incidental. This is why we could go to the Moon in a decade but can't build a replacement for the Space Shuttle in that time. If we had to rebuild the Hoover Dam or the Empire State Building these days, there's no possible way it'd ever be done in the timeframes of the original projects. It's a bit sad, really.

patentatt 9y ago
I think the real problem here is that the mainframe assembler codebase is undocumented, and decades of idiosyncratic corner-cases and bug fixes are only present in the source code. If the system was fully documented, it could be trivially re-implemented in any language or platform of choice. That's why I think this kind of "modernization" project can be really useful, because it forces the organization to define its requirements. Edit: Just to take this concept a little but further, I'd argue that "software" is an illusion. Most software, and nearly all 'enterprise' or 'business' software should be able to be fully defined and written on paper, by humans, before a single developer is engaged to translate those requirements to something a computer can run. The exceptions would be more elaborate things like video games, AI stuff, and things that rely on computers to do what they do. Anything that is automating what humans do (like the IRS here) should be written on paper first, code second. All too often non-technical management doesn't understand this, as it's boring and hard. It's easier to throw money at 'consultants' to pry the requirements out of them and then complain at how expensive the "software" is - while the real expense is just asking your business people what they actually do.
- taborj 9y ago
  > Most software, and nearly all 'enterprise' or 'business' software should be able to be fully defined and written on paper, by humans, before a single developer is engaged to translate those requirements to something a computer can run. This was literally day one of my systems architecture class in college, over 20 years ago. It's probably done more often than you think, but the problem is the workflows change slightly over time, and rather than go back to the drawing board each time, they just tweak the systems software. The result, though, is a mess.
  - patentatt 9y ago
    Surely it's not unheard of, but as a former 'consultant' I would always be amazed that the client hadn't documented their workflow by the time we showed up. We'd usually have a team of BA's work with the client for a few months before code was written, all because the management didn't know how their business ran. Reading between the lines here, it seems that perhaps the IRS is in a similar situation, and the only canonical source of truth for how things work is encoded in the assembler source code.
Lionsion 9y ago
> I think people seem to forget that newer does NOT mean better, and that an old, slow computer which is reliable is infinitely better than a new, fast computer which is either unreliable or idiosyncratic (or both). In this case, though, I think there's a good case: the existing code is written in IBM mainframe assembler and needs to be regularly updated. IMO, your argument really only works when the system needs little maintenance. If the system requires regular active development, then there's a strong case for staying aligned with the workforce's skillset. > The article made no real case for the replacement of the IRS' computers. Sure, there's a case for updating their software, but this isn't the same thing as what the title says. I think the headline was badly written, and the software problem is what it's really talking about: >> Though the IRS has periodically upgraded its computing system, today’s system is still running the same code, which was written nearly 60 years ago. Most of it is in the Assembly programming language, which the IRS itself has described as “antiquated” and “inflexible.” [emphasis mine]. They've actually replaced the computers several times, but they never replaced the software with something that was easy to maintain.
pbhjpbhj 9y ago
I agree with most of what you say, but if an old computer system could not, say, complete its yearly tasks in a year then replacing with a faster processing system would make sense. It's not unheard of for a mainframe to take of-the-order of a day to do something that needs doing each day.

patentatt 9y ago

I think the real problem here is that the mainframe assembler codebase is undocumented, and decades of idiosyncratic corner-cases and bug fixes are only present in the source code. If the system was fully documented, it could be trivially re-implemented in any language or platform of choice. That's why I think this kind of "modernization" project can be really useful, because it forces the organization to define its requirements. Edit: Just to take this concept a little but further, I'd argue that "software" is an illusion. Most software, and nearly all 'enterprise' or 'business' software should be able to be fully defined and written on paper, by humans, before a single developer is engaged to translate those requirements to something a computer can run. The exceptions would be more elaborate things like video games, AI stuff, and things that rely on computers to do what they do. Anything that is automating what humans do (like the IRS here) should be written on paper first, code second. All too often non-technical management doesn't understand this, as it's boring and hard. It's easier to throw money at 'consultants' to pry the requirements out of them and then complain at how expensive the "software" is - while the real expense is just asking your business people what they actually do.

taborj 9y ago
> Most software, and nearly all 'enterprise' or 'business' software should be able to be fully defined and written on paper, by humans, before a single developer is engaged to translate those requirements to something a computer can run. This was literally day one of my systems architecture class in college, over 20 years ago. It's probably done more often than you think, but the problem is the workflows change slightly over time, and rather than go back to the drawing board each time, they just tweak the systems software. The result, though, is a mess.
- patentatt 9y ago
  Surely it's not unheard of, but as a former 'consultant' I would always be amazed that the client hadn't documented their workflow by the time we showed up. We'd usually have a team of BA's work with the client for a few months before code was written, all because the management didn't know how their business ran. Reading between the lines here, it seems that perhaps the IRS is in a similar situation, and the only canonical source of truth for how things work is encoded in the assembler source code.

Lionsion 9y ago

> I think people seem to forget that newer does NOT mean better, and that an old, slow computer which is reliable is infinitely better than a new, fast computer which is either unreliable or idiosyncratic (or both). In this case, though, I think there's a good case: the existing code is written in IBM mainframe assembler and needs to be regularly updated. IMO, your argument really only works when the system needs little maintenance. If the system requires regular active development, then there's a strong case for staying aligned with the workforce's skillset. > The article made no real case for the replacement of the IRS' computers. Sure, there's a case for updating their software, but this isn't the same thing as what the title says. I think the headline was badly written, and the software problem is what it's really talking about: >> Though the IRS has periodically upgraded its computing system, today’s system is still running the same code, which was written nearly 60 years ago. Most of it is in the Assembly programming language, which the IRS itself has described as “antiquated” and “inflexible.” [emphasis mine]. They've actually replaced the computers several times, but they never replaced the software with something that was easy to maintain.

pbhjpbhj 9y ago

I agree with most of what you say, but if an old computer system could not, say, complete its yearly tasks in a year then replacing with a faster processing system would make sense. It's not unheard of for a mainframe to take of-the-order of a day to do something that needs doing each day.