Call for Code – Developer competition that seeks solutions for natural disasters
developer.ibm.com
developer.ibm.com
It does seem like IBM has been caught out by freely available alternatives which are simply better at most scales. It reminds me of what happened to companies selling compilers or corporate VOIP solutions; they didn't just fail to keep up with the market, their entire market was supplanted by open-source solutions and single features in much larger offerings.
IBM has made a fairly productive effort to avoid that, I think, via their consulting/outsourcing divisions and value-added things like cloud solutions. As a result, their data science products are still appealing in terms of ecosystem integration and strong support options for less-technical buyers. But that doesn't seem like a wonderful position to be in long term, since it puts them in competition with AWS/GCP on one end and free tools on the other.
Maybe I'm being naive but what do their 350,000 employees actually do? That's nearly as much as Apple, Google and Microsoft combined.
However, like you said - brilliant fellows aside, IBM employees as a whole are much less technical.Most would never pass a tech interview at FAANG.
I used to think it was "make chips", but they contracted that out a few years back. IT outsourcing is a big part of it, which tends to drive up staff numbers much faster than in-house projects. They're also still fairly big in business tech like POS systems, although I think that's been shrinking?
(I suppose the other answer is "IBM doesn't know either", given that they've made huge staff cuts to a lot of their older divisions.)
IBM has a cultural issue that will take far more than strong leadership to change - starting to change those incentives would require a disruption to IBM's business model that could truly hurt short-term financial performance, way more than Microsoft's "hey let's start releasing dev tools for Mac/Linux in ways that don't actually cannibalize PC sales - it's not like those devs were going to switch to Windows anyways - but do make it easy for them to become long-term Azure users."
And rather than fighting on the dev-tools turf, they're trying to gain mindshare with AI-as-a-service for people who aren't really innovating in AI. I'm looking at the icons in my Mac's Dock right now, and Microsoft's winning a ton of them with best-in-class IDEs and productivity software. Watson isn't in every startup developer's Dock. Now, if IBM bought Tableau and moved Cognos in that direction, adding generous free usage tiers, maybe they get Watson-branded icons on that Dock? But I doubt this happens any time soon.
1. mid-level staff that's not technical, unable to get results quickly (one tends to get that mentality from massive open-ended consulting engagements w/o clear success metrics in place)
2. surreal TV ads aside, their brand is not visible on a daily basis, there's no consumer offering with IBM logo on it
3. there is no modern cloud offering (Softlayer ain't one)
4. their marketing of Watson has been so extreme, and so out of touch with technical realities, it's becoming a liability
1. solid mainframe business (yes)
2. massive customer list
3. significant infrastructure (softlayer etc) that could be turned into a cloud offering
4. huge long-term consulting engagements that can turn into success stories, if run by ppl capable of delivering quick results
One more thing I would do if I were CEO - I would come up with a way to put that IBM logo in front of people... Perhaps something along the lines of "Alexa for business", based on IBM's flavor of business AI.
Of course, the new direction he set them on (stop developing innovative things, focus instead on high-margin consulting and services) is the one everyone's complaining about now. So...
I think autonomous systems and AI can greatly reduce the cost of disaster recovery. Search and rescue using drones for example, the NASA Autonomy Incubator was working on a system like that with MIT while I was there [1].
Two examples that come to mind: Facebook developing their "check in as safe" feature for disasters, and Uber adding one-sided surge pricing so that they can respond to post-disaster demand without raising prices. Uber's move was mostly about fixing a prior oversight, but Facebook's has provided some fairly novel benefit. Basic mobile internet is both more widely available and more disaster-proof than other communications, so it's a welcome improvement on "people flood the phone system trying to call loved ones".
That said, the biggest opportunities here seem to be in disaster-awareness from developers of existing software. IBM's pitch of "come create novel software for disaster response" looks rather less convincing.
do
pray();
while (badThing);
The benefit is that it directs the attention of the community at large towards the problem. This raises awareness with the hope that those with the means to help will do so.
Its an anti-fragile method of asking the community for help without knowing the specifics of how they can help.
actually, now that I think about it, "Thoughts and Prayers" is no different than a "Call for Code" except that it is generalized to all society instead of just software developers.
We need to start controlled abandonment of those areas already many decades early - starting from not investing more into building there.
This is a very cheap way of massive scale disaster preparedness: not having people where the disaster happens.
There's a paper that proposes long term property insurance, which makes it seem the one year contract is the standard? http://opim.wharton.upenn.edu/risk/library/J2010(JIR)_DJ,HK,...
If your neighborhood floods, that's a bunch of insurance claims, but if your city floods, that's potentially a bailout, bankruptcy, or contract exemption for the insurer. (In some cases, like sea level rise in Florida, there's already an understanding that the state is subsidizing insurance that wouldn't be available otherwise.)
So I could definitely imagine some value for a buyer-focused service that carries information about all known risk, not just covered/unsubsidized risk.
Otherwise, because of future known risks, it would be untenable.
Also, many formerly vacant parcels of land known to be in the likely paths of hurricanes, have become subdivisions.
I guess that is why flood insurance is a separate and optional policy?
> Blockchain
Ironic that such a power-hungry technology be used in dealing with natural disasters. If anything, it's just contributing to global warming. Can we please stop pretending that everything on Earth needs a blockchain?
As a currency (and a lot of other hyped applications), I agree with you, almost totally useless.
The things they're advertising here just aren't the things that disaster teams need. Nobody on a natural disaster has ever said, "you know what would make this so much easier? ...Blockchain."
The only part of the Camp Fire that would satisfy a tech boner would've been Alameda County's drone team. It turns out that they've been fostering a pretty good drone team and they were able to do flyovers of large sections of the disaster area, capturing imagery down to 1cm resolution and piping it back to a mobile GIS center that looked straight out of an episode of CSI. Their work was good enough to satisfy the requirements for a lot of insurance adjusters who would ordinarily have had to physically visit the site. It could've sped up the entire search and recovery operation by several days if it weren't for CalFire's insistence on redoing all of it with pen and paper.
The number one technological need for disaster work is communications, hands down. One of the first pieces of infrastructure that falls apart during a major disaster is communications, and it's also the most urgent tech problem to solve, every time, because you can't have teams out in a disaster area with bad comms. We really need some kind of reliable, fast-deploying, low-maintenance radio and cellular infrastructure, and nobody's figured that out yet.
Probably the next big pain point is GIS or data management. Our current GIS software is good enough in the hands of skilled operators, but getting data into and out of it is labor intensive and its dataviz isn't exactly cutting edge. A mobile app that interfaced well with it and allowed search teams to bring up a search segment with a limited amount of data through a text message or QR code would be badass.
On the data management side, every single event, item of interest, and squawk of radio traffic has to be logged. Every single one. For a big disaster, this turns into reams and reams of dense paperwork and hundreds of man-hours to compile it all. And when teams arrive at IC in the morning, they have to fill out information cards and receive printed packets every single time, because there's no state-level coordinated database of DSWs and no way to quickly organize them by skillsets. This slows down deployment by around 2 hours in the hands of a top-of-the-line management team, and by much more when the incident management team is less experienced.
If you're seriously interested in pursuing any of this, feel free to contact me at the email address in my profile.
We've already started inter-agency training events for this year's next wildland-urban-interface fire.
Thank you for such a detailed, informed and relevant comment. Merits tons of upvotes.
My first thought reading the prompt was that "build tech for disaster recovery" is exactly the wrong direction of approach. There's far more good to be done, more efficiently, by taking existing systems in one category and finding places they can help in the other. "Adding disaster support to tech" might look like Facebook's safe-check-in feature, and "adding tech to disaster recovery" looks like everything you describe.
I would imagine the military truisms about technology are every bit as true in disaster management - namely that everything works right up until you need it, and has all the features you don't want but none that you do. Availability tracking for antibiotics sounds great, but it's probably useless unless it works over a crowded 2G connection and lets you manually alter records when the shiny inflow/outflow features can't describe reality. ("Blockchain for supply chain tracking" sounds particularly egregious; when you find out somebody mislabeled things five transactions back, what the heck do you do about it?)
Everyone I've known developing for outdoor or rural use is less interested in features than in redundancy, flexibility, and low-tech functionality. It'd be very interesting to work on something like bringing the easiest-to-use GIS solutions for hiking, research, or land development over to disaster recovery (assuming they're better than what you have). There are probably far fewer people qualified to build field-deployment cell infrastructure, but that also sounds fascinating. And all of it sounds far more useful than the IBM challenge.
I hadn't heard that before, but yep, that's about right. Especially when it's been developed by people without a lot of field experience.
> It'd be very interesting to work on something like bringing the easiest-to-use GIS solutions for hiking, research, or land development over to disaster recovery (assuming they're better than what you have).
I hasten to clarify here that we don't really want to give up what we've got already for GIS, we'd just love some help extending it. What we use is a specialized offshoot of https://caltopo.com/, built by the same developer but with additional features designed for search operations. That developer is himself a very experienced and well-liked search and rescue volunteer, and that experience is reflected in the features in the software (including the ability to host it locally). There's going to be a high bar to leap over to adapt anything else to fit the same niche and get the trust and adoption that sartopo already has.
But, for various good reasons, we still rely primarily on handheld Garmin GPS units for ground work. These need to be physically connected to a computer to get map data loaded and then search activity unloaded. It takes almost two minutes per device per operational period if nothing goes wrong, so in a massive multi-agency search, you can imagine the bottleneck this creates.
As a fall-back, we've started trying to use Avenza. It's ... okay. Anybody can walk up to a wall with a big printed QR code and start using their smartphone for navigation. But it still requires a network connection to get the search area loaded and it's not really ideal for retrieving search activities when a ground team returns to IC.
So what would be really sexy is an iOS/Android app that copied basic Garmin features, but had area map data stored locally (a la HereWeGo), and could communicate directly with sartopo to download segments and markers and upload tracks. That would be sooo nice.