Boston has had an electrical fire alarm system for over 100 years. There are hundreds of call boxes located on city streets. You pull a handle on one of those boxes and an alarm rings in the city's Fire Alarm building. The dispatcher can determine which box was pulled and the location. The city licensed the technology from Samuel Morse, who was living in town at the time. There's a modern digital system as well, but the fire alarm boxes still work
(I've been inside the Fire Alarm building and seen the original wiring from the 1920s. It is beautiful.)
But do other cities use the system used in Boston? That seems to me to be the root of the problem: a lack of standard ways to do standard things. Here in my city I once got involved with a system that:
* sent serial characters over a modem on a dedicated phone line.
* the characters ended up in a hacked printing terminal.
* that closed a relay that rang the gong in the fire station after the printing terminal had generated the associated document.
So yay! We solved the problem. Unfortunately such "one off" systems tend to be maintenance nightmares (which is where I came in).
Even more remarkable that the person who gave testimony on it is named Charles Moore. I'm assuming it isn't the Charles Moore who invented Forth - although that would be wild.
I might be alone in this, but I read this article with a sense of giddiness. Not because I want to see Detroit suffer or fail, but because this is a chance for a city to completely start over, even technologically.
It's almost never the case that a city is in such shambles that implementing a completely new technological base would cause less problems than maintaining the current one. Since it seems Detroit is completely lacking in any technological foundation currently, this could be a huge chance for them to remake themselves.
With the huge rush of municipal ISP's, availability and dependency of open source software, and numerous intelligent startups, Detroit is in a position to because an incredibly techno-smart city.
Yes I know this would cause issues, and it would change the dynamic of the city. However, I think facing those problems, and creating all those new jobs provides a significantly higher potential for stability than whatever the auto-industry can offer while still not using robots completely manufacture cars.
Regardless though, this article holds true. Detroit needs to advance, faster than it ever has in the past, and I really hope they succeed.
This is the gist of what their mayor's office has been saying, except they've placed more importance on renewable energy and sustainability. Detroit, lacking everything, is also in a good place to compete to be the greenest.
> For example, it costs $62 for the city to cut a single payroll check
This is stunning to me. From some rough calculations, even with very generous estimates, it cost about $8 to cut a payroll check back when I was in charge of payroll processing for a medium (5k employees) sized company.
> The payroll system consumes the daily work of 149 full-time employees, of which 51 are full-time police officers.
This sounds like a municipal bloat problem, then, and not an IT problem. In fact, I would bet that most of the city's IT problems are merely symptoms of the larger problem.
The city of Detroit indirectly attempted and failed to create a psuedo-socialist state within itself (I'm a Detroiter).
The City in and of itself is the largest employer within its own boundaries, because when the city wanted to create new jobs. Its very easy to expand services, hire new people. Bam new jobs created, and then you can hire directly from city people, city people stay in the city. Tax dollars come back to your pocket :D
The problem is then those people who get jobs, move into the suburbs, and the city loses money because what it hoped to regain in taxes back to itself, never came.
What this leads to is a TON of people on city pensions, and city health care who don't live in the city, and haven't for years. Collecting city money, that's simply being exported to near by suburbs.
I've never understood this type of employment logic from a city's perspective. The city employs a large number of people within it's boundaries, supposedly in an effort to keep tax revenue inside the city. But these people's paychecks come from tax revenues in the first place. So unless they have new monies coming in somehow, it's a circular logic problem that degrades over time until it collapses.
You hit the nail on the head. Sort term (5/10 years) solutions get you reelected. Long term 25-50 years, get you kicked out after 1 term for a lack of progress.
I guarantee you that whatever mistakes the city government in Detroit made, above and on top of socio-economic things that are hard for them to control, nobody ever said "I know, we'll create a socialist mini-state in detroit and that will fix things". That definitely didn't happen.
I'm just saying it's silly to call the government socialist based on the gov't % of jobs growing in an otherwise shrinking economy. The government could be cutting jobs (not that Detroit's is) and still growing as a % of a shrinking-faster economy.
BTW, there's nothing wrong with Windows XP except its planned obsolescence. AFAIK, an organization can pay Microsoft to extend the support for XP which probably is the cheapest solution for the town.
BTW, there's nothing wrong with Windows XP except its planned obsolescence.
Huh? But I agree that Custom Support costs only a few hundred thousand for the first year at a minimum, but note that the price do increase year to year.
Agreed. Though the article's title lists Windows XP as the city's major problem, it appears to be the least of its worries. The major bank I work for is just now standardizing everyone up to Windows 7. We've done the majority of our work in Office 2003. Though it is frustrating at times, it has not dragged us into bankruptcy. It sounds like upgrading to a modern operating system should be near the bottom of the list of things Detroit needs to do at the moment.
Most coders just happen to like coding. Selling IT services to a government might involve a little coding, but it's mostly about mastering the procurement process. Where do you even start with that?
Yea, I work quite a bit with government contracts, and to be honest it's a lot of fun and it offers some very interesting projects and R&D opportunities. But I work for mid sized consulting group that has at least two layers of insulation between me and the customer. My boss is an absolute hero for dealing with the stuff he deals with to make sure I just get to code. There is no way in hell I'd try to get involved in that world if I had to deal directly with the whole procurement process myself.
Also I try to only take smaller projects (up to $100000 or so) since they tend to be handled by much more sane people all around.
There may be some pointers here applicable to the US scene. Nevertheless, it's good to see management finally realizing the cost benefits of smaller-scale operators.
In Medellin, Colombia, they have this fair about government transparency where the local governments shows to all participants all the different projects, how much was paid, who participated and specially relevant for your comment, they teach people and companies how to participate in the whole process.
And a subset of those problems are the insane RFPs and ridiculous red tape you go through when you design stuff for the government. Try it sometime. It's a blast.
I think a bigger issue is that it's (at least perceived to be) hard to deal with government for anything. Plus this is about physical infrastructure. I think many coder's fascination with train networks and the like would help fuel an interest in fixing Detroit IT, but those meatspace issues...
Well I don't use Red Hat but when I update Debian Stable, my system doesn't break, and I don't have to pay for 500 site licenses. My system benefits from people that ensure emacs and libre office will work if I update glibc.
The same is not true for Windows, where XP obviously gets dropped with no sane upgrade path and a non trivial cost.
I don't want you to interpret what I'm going to say as talking down to you, but it'll sound that way.
It's clear you've never worked in desktop support if you think that your personal experiences upgrading your computer apply to any kind of wider deployment.
There are issues training staff, maintaining a fleet of compatible hardware, compatible software etc. This all costs money and will - two things Detroit clearly didn't have. Making the software "free" may in some cases bring one cost down, it may also inflate costs in the other parts of the equation.
I personally don't use Windows in my computers, but I have supported networks that do and participated in a Windows XP to Windows 7 upgrade project. You have to hand it to Microsoft, if you stay within their support windows then it's remarkable how well their upgrade path works. The money you pay them is actually buying very polished system.
I think you're both right to some extent. Both approaches have difficulties, just different ones.
The open source approach can have lower up-front costs (but isn't guaranteed to have...), but it requires talent that's harder to find and more expensive as a result. There's also the problem of user resistance, as you point out. We have enough trouble just getting users to use FF/Chrome instead of IE; Linux desktop systems wouldn't go over very well and would require a ton of effort. That's not even touching the problem of a lot of infrastructure being irreversibly tied to software that expects to run in a Windows environment.
But the Microsoft stack can also incur a lot of up-front expenses for larger organizations, and license management isn't very easy either. And, it has its own issues and glitches.
Just to pull a number out of my butt, I'd guess a city like Detroit would be looking at millions in Microsoft licensing costs alone if they were to upgrade their entire infrastructure.
And XP->7 isn't usually too bad, but there are some recurring problems we've encountered (Quickbooks), and XP->8 doesn't work at all.
There's also some companies doing SAAS apps for cities. I hope Detroit jumps ahead of other cities in using the cloud. Maybe even replace some of those aging computers with Chromebooks.
The one thought I have is that every city is guaranteed to have different laws regarding its charter/governing contract. That might dictate a lot of how that software interacts.
That being said, might be an area to make a killing having a highly-modular City CMS you can sell for half the price of contracted software.
The federal nature is a blessing and a curse, since though it's highly variable, you can sell this to one city without getting the rest of the nation to agree on it as well.
> the database was created at a time when encryption wasn’t used.
Apparently I'm relatively new to technology, but when was this time when "encryption wasn't used?" It seems so fundamental today that I can't imagine a world without it.
Back in the days where if you had a disk that implemented it, it was illegal to take with you to another country (the vestiges of such laws are still around today as a relic of that time).
Mass adoption of encryption over the wire dates to the late 1980s for cell phone standards, and late 1990s for Internet communications.
Of course, most Internet traffic to this day is still not encrypted, including email, which travels over the wire as plain text!
Encryption at rest is harder to nail down; in my experience it has caught on quite a bit slower than over the wire. Until recently, it seems like most orgs believed that local network security meant they didn't have to encrypt data at rest.
Here is an entire documentary from that time: http://www.bbsdocumentary.com/ - it's over five hours long. We used to use modems to connect directly to our friends (and sometimes, enemies), send and receive mail, play games, and lots more, all in the clear. This period of computer networking history lasted much longer than the one where encryption was used most of the time, so far.
Back in the day when you needed physical access to the computer itself that was behind many locked doors and possibly guards because networking and the internet didn't exist, I could see not needing encryption.
These days it's not that we need encryption, apparently we need stronger encryption and proper training for people who handle other people's data.
Boston has had an electrical fire alarm system for over 100 years. There are hundreds of call boxes located on city streets. You pull a handle on one of those boxes and an alarm rings in the city's Fire Alarm building. The dispatcher can determine which box was pulled and the location. The city licensed the technology from Samuel Morse, who was living in town at the time. There's a modern digital system as well, but the fire alarm boxes still work
(I've been inside the Fire Alarm building and seen the original wiring from the 1920s. It is beautiful.)