Slashdot Mirror


America's Cities Are Running on Software From the '80s (bloomberg.com)

Even San Francisco's tech chops can't save it from relying on computers that belong in a museum. From a report: The only place in San Francisco still pricing real estate like it's the 1980s is the city assessor's office. Its property tax system dates back to the dawn of the floppy disk. City employees appraising the market work with software that runs on a dead programming language and can't be used with a mouse. Assessors are prone to make mistakes when using the vintage software because it can't display all the basic information for a given property on one screen. The staffers have to open and exit several menus to input stuff as simple as addresses. To put it mildly, the setup "doesn't reflect business needs now," says the city's assessor, Carmen Chu.

San Francisco rarely conjures images of creaky, decades-old technology, but that's what's running a key swath of its government, as well as those of cities across the U.S. Politicians can often score relatively easy wins with constituents by borrowing money to pay for new roads and bridges, but the digital equivalents of such infrastructure projects generally don't draw the same enthusiasm. "Modernizing technology is not a top issue that typically comes to mind when you talk to taxpayers and constituents on the street," Chu says. It took her office almost four years to secure $36 million for updated assessors' hardware and software that can, among other things, give priority to cases in which delays may prove costly. The design requirements are due to be finalized this summer.

13 of 211 comments (clear)

  1. Dead Programming Language? by Medievalist · · Score: 5, Funny

    It's Java, right? Tell me it's Java!

    1. Re:Dead Programming Language? by juniorkindergarten · · Score: 5, Insightful

      Cobol.

      --
      "Every security scheme that is based on secrets eventually fails." - Steve Jobs
    2. Re:Dead Programming Language? by Anonymous Coward · · Score: 4, Insightful

      There are probably millions of retired COBOL programmers out there who wouldn't mine working again for a little while. But they don't have "current" experience.

    3. Re:Dead Programming Language? by spudnic · · Score: 4, Insightful

      That still doesn't mean you couldn't put a web based front end that talks back to the cobol running on the AS/400 (iSeries). We do this all of the time. The cobol is probably very fast and efficient. It just needs a better user interface.

      --
      load "linux",8,1
  2. That's because their programmers were skilled by Anonymous Coward · · Score: 5, Insightful

    You can read the headline as a denigration of governments (which is always valid, because they get paid regardless of their performance), but you can also read it as proving that the programmers of the 1980s produces some pretty solid work.

    1. Re:That's because their programmers were skilled by thereddaikon · · Score: 5, Insightful

      The average professional developer of the 80's was probably better at their job than the average one today. For one, they actually had a working understand of the hardware on a conceptual level and could relate how their code would interact with the system. Ask your average JS coder how a computer works and grab some popcorn. Due to the limitations of distribution methods and storage media of the time software was also far less bloated and much more stable at launch. You couldn't easily patch something post launch like you can now so you had to get it mostly right the first time. There is no such thing as bug free code but there is code with some bugs and then there is code that is mostly bugs.

    2. Re:That's because their programmers were skilled by sfcat · · Score: 4, Interesting

      For one, they actually had a working understand of the hardware on a conceptual level and could relate how their code would interact with the system. Ask your average JS coder how a computer works and grab some popcorn.

      There's definitely a lot more going on nowadays with both the OS and application layer libraries. I doubt anyone can understand the entire stack the way people did back then.

      In fact, I'll bet you can't figure out what machine code a simple line of JS code turns into either. And even if you did, that answer would be wrong in a few weeks when the next release of V8 comes out.

      Due to the limitations of distribution methods and storage media of the time software was also far less bloated and much more stable at launch. You couldn't easily patch something post launch like you can now so you had to get it mostly right the first time. There is no such thing as bug free code but there is code with some bugs and then there is code that is mostly bugs.

      I seem to recall a lot of older software that had a final version named something like 1.0.4. And those were only made available months after the initial release. In other words, you'd have software with glaring flaws that you'd have to put up with for months. Versus now, any major bug would be quickly patched up post launch and it's a matter of a few days, or even just a few hours of waiting.

      Hahahahaha, modern software that is quickly patched is also broken about 99% of the time.

      I recall products and code actually working as designed in the 80s. They had computers you could literally pull a running CPU out of the board and it would still continue to work correctly. If you think today's software is anywhere near as well written or reliable as software of the past, you are a fool. Today's software business is built on cheap coders pushing out crap as fast as possible. In the past we did actual engineering and testing to make sure things worked before we gave them to users. Today, we let the users's beta test software live and 'let it crash' is the moto of the ops folks.

      --
      "Those that start by burning books, will end by burning men."
    3. Re:That's because their programmers were skilled by MBGMorden · · Score: 4, Informative

      Depends. I work in such a government office. Our property tax billing software is written in COBOL, was first written in the very early 1980's, and does generally work well.

      HOWEVER - whew boy is that some weird code. Nothing is driven by configuration tables. Pretty much every behavior is hard coded into the program. Even for security permissions like who can access which screens, there's literally a user ID HARDCODED into the source.

      And god help you if you need to something like widen a text field (all of which are notoriously small due to being defined back when disk space was much more expensive). You'll have to recompile dozens of programs that hit that file, and often times when it's absolutely necessary we have to cobble together fields to make a bigger one (ie, positions 1 through 30 of a field might be in the middle of a line, 30 through 40 towards the end, and then 40 through 50 in another field at the very end of each line.

      Rather than being an example of how good the code is, I think it's more an example of the fact that even for bad (or even terrible) code, if you've had 30 years to debug it it'll still function fine. It's an unmanageable mess, but it does indeed do exactly what its supposed to.

      --
      "People who think they know everything are very annoying to those of us who do."-Mark Twain
  3. Because it works... by TWX · · Score: 4, Insightful

    ...and is optimized to run on extremely slow hardware. It was often written by people that were extremely talented at optimizing their code because hardware limitations forced them to do this.

    I won't deny that advances in computer language have made it possible to write programs better than they used to be written when machines were extremely procedural and single threaded, but at the same time, the amount of bloat in modern programming afforded by modern hardware has more than made up for it.

    I've seen the progression of software for simple things like workorder systems and asset management and audit get worse over time. The only 'improvement' is access, in that going from an 80x25 text console on a remote system with terminal emulation, to a a full-fledged program running on a specific architecture in a text mode, to a GUI program on a specific architecture, to 'applet' type programs using runtime libraries cross-platform, to web-based access that theoretically are entirely platform independent presuming a minimum browser version, and in just about all cases the further they've gone, the slower clunkier for actual experienced users that frequently use the system. It might not be any better for inexperienced users either if the vendor hasn't taken the time to look at workflow from an outside point of view.

    --
    Do not look into laser with remaining eye.
    1. Re:Because it works... by SurenEnfiajyan · · Score: 4, Interesting

      Yeah, today's bloat is incredible, and this era of shitty programmers with their toy programming languages is very disappointing. One can only imagine how many CPU cycles and electricity is wasted. Just a fun fact, Windows 95 required less ram (sometimes in order of a magnitude) than a basic calculator in any modern OS.

    2. Re:Because it works... by Anonymous Coward · · Score: 4, Interesting

      It blew my mind when I ran the Windows 10 calc.exe for the first time on a HDD system. It had a measurable loading time.

      A program function as old as windows which was snappy on a 386 now has a human noticeable loading time-and a link to a privacy statement! But that's another rant.

  4. Awesome! by DogDude · · Score: 5, Insightful

    I think this is awesome. It was good software that hasn't needed to be "updated" every other day like modern software is.

    --
    I don't respond to AC's.
  5. A mouse? by Hugh+Jorgen · · Score: 5, Insightful

    A mouse would not increase efficiencies, look at the horrid inefficiencies of web applications. The lost productivity when IBM forced one of their large financial clients to move from a 3270 green screen app for change management to web app caused outrage. Most UI/UX people do not use the tools they design. Is there "technical debt" here, likely. Does the new app need to support a mouse or be web based? Likely not.