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.

8 of 211 comments (clear)

  1. 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. 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.
  3. 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.
  4. Re:Dead Programming Language? by juniorkindergarten · · Score: 5, Insightful

    Cobol.

    --
    "Every security scheme that is based on secrets eventually fails." - Steve Jobs
  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.

  6. 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.

  7. 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