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.
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.
It's Java, right? Tell me it's Java!
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.
...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.
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.
'can't be used with a mouse'
Which describes an entire era of software. Was ti useful before a mouse was considered so vital, actually before it was even used, or existed? Well, back then it was specified, purchased, and used. Same as now, this is a specious argument.
'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'
Dear, it seems as if either this software was NEVER usable, or are users able to take the necessary care to do their work accurately...?
'The staffers have to open and exit several menus to input stuff as simple as addresses'
Ah, the slings and arrows.
'To put it mildly, the setup "doesn't reflect business needs now'
As in ease of use, etc, sure. As in it has always worked like this, why do I seem to read this as 'it's old and clunky, and it's the fault of the software that I make so many mistakes'. Where I work, we do have a lot of this. Because we care, and work in private industry, we understand the software, make the necessary adjustments to our habits, and take the time to do it right.
'It took her office almost four years to secure $36 million for updated assessors' hardware and software...'
'The design requirements are due to be finalized this summer.'
What comes first, the chicken, the egg, the funding, or the requirements?
After all that, has no one in San Francisco government made a CBA case for replacing it? I'm betting they are leaving revenue on the table by not having accurate data. And I'm betting they need to build reasonable, achievable requirements. So many government IT projects fail because the project was designed so poorly from the start.. Examples abound.
deleting the extra space after periods so i can stay relevant, yeah.
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.
Have you seen the average worker at the DMV? They're not exactly the sharpest knives in the drawer.
Light travels faster than sound. This is why some people appear bright until you hear them speak.........
So what you are saying indirectly is that you are the brain-damaged one since you speak of things you have zero knowledge of. VMS was one of the best designed OS's ever. It was light years ahead of all the Unix's flavors at the time.
AS/400 based system are some of the most reliable systems money can buy. They can handle insane amounts of workloads and can scale from small systems to complete mainframes.
OK, so I was actually looking into this a few days ago. I'm working on modernizing our build system, part of which includes running Jenkins jobs on AIX servers (to build an AIX client module. Whatever.) We fire off around 10 parallel jobs to build on AIX, Solaris/Sparc, Solaris/x86, Windows, Linux/x86, Linux/x64, and so on. I wanted to understand which ones take the longest because that's what I have to optimize.
Funny, the AIX, PA-RISC, and SPARC systems get absolutely crushed by any x86 system. They may get a lot of work done per CPU cycle but the newer systems have just so many cycles it doesn't matter. AIX, HP-UX, and Solaris might be heroes at getting lots of transactions done on a 100 MHz processor, yay for Big Blue, HP and SunSoft, but if I care about actual absolute throughput, just nope.