
Call for Code – Developer competition that seeks solutions for natural disasters - hownottowrite
https://developer.ibm.com/callforcode/
======
wajdix
It is just a stunt from IBM to promote their WATSON software. a 200k$ prize is
a small price to pay to get dozens of smart people to team up and
work/test/enhance your products for free...

~~~
mv4
It's more than that. IBM is trying to win developer mind share, future tech
decision makers are strategically important to them in their current
situation.

~~~
marsRoverDev
I think they might need to accelerate their efforts, I think a lot of people
here look at them in a very negative light.

~~~
cameronbrown
I'd love to see a CEO do for IBM what Satya did for Microsoft. A lot of OSS
people thought they were the devil, and yet they've turned that around
massively. Unfortunately it seems (from the outside) that IBM is just
organisationally crippled from size bloat at this point.

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.

~~~
btown
Microsoft had a tremendous headcount as well. But I think that there is a
subtle and important difference. Developers at Microsoft see themselves as
product creators - and within every creator is a passion for the craft that
good leadership can unlock. IBM, to my knowledge, has a much larger proportion
of their headcount who are "contract maintainers" \- doing contracted work
where their KPIs implicitly optimize for "how long can we keep/grow this
contract" rather than "how good is the product created."

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.

------
rdiddly
Do people really think _software_ is the element that's missing from current
disaster prep & recovery efforts? I would've picked _money_ or maybe
_leadership_. Maybe I'm unimaginative.

~~~
Bartweiss
I certainly don't think missing software is the problem for disaster recovery,
but there's something to be said for the idea that disaster recovery is
missing from software instead.

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.

------
ikeyany
This piece of code has been run for thousands of years and I see no reason why
it shouldn't work now:

    
    
      do
        pray();
      while (badThing);
    

I accept PayPal.

~~~
jxub
I don't think that pseudocode would work, I'd be more inclined to use
something moral and secure like Rust.

~~~
Isamu
Surely we can encode morality in blockchain

~~~
8ytecoder
I feel like a trojan that hijacks all existing blockchains and kill them would
do more good to climate change than any other idea we could possibly come up
with. We are burning an awful amount of electricity on something that's not
being used for any practical purpose but only by speculators and "investors".

------
wishrider
I could build a disaster-response version of my wish page
[https://wishpage.tv/places](https://wishpage.tv/places) People could place a
request (or a wish) on the map, that request is public and visible. People at
the location can pick up a request (e.g. to make a video or to fly a drone
over a volcano). Other people can up-vote requests and even attach money to
them (rewards for fulfillment).

------
Gravityloss
An idea: provide a service for house buyers and job seekers: see which cities
and neighborhoods are in danger of being inundated in the future. Probably it
could be integrated with some real estate platform - calculate a simple risk
score for the listing using open elevation and traffic data.

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.

~~~
deelowe
Do insurance companies not already do this sort of thing?

~~~
Gravityloss
I don't know if they look so far ahead? Ie if insurance is just for a few
years at a time at once?

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,...](http://opim.wharton.upenn.edu/risk/library/J2010\(JIR\)_DJ,HK,EMK_LongTermProptyIns.pdf)

~~~
deelowe
Ahh. That makes sense. So insurance is more interested in the potential for a
claim within the current policy cycle and not the long term risk.

~~~
Bartweiss
That, and in some cases highly-correlated risks get dismissed altogether.

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.

------
cameronbrown
This is very much buzzwords-first and not problems-first.

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

~~~
roro159
Blockchain != PoW. There are plenty of blockchains without the problems you
described (like IBM's Hyperledger).

~~~
dillonmckay
Also blockchain != distributed.

------
thaumaturgy
Oof. I've got some training and experience in disaster management, including
being a part of the overhead team for the Camp Fire last year through my
county's search and rescue team.

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.

~~~
Bartweiss
This is fascinating, thank you.

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.

~~~
thaumaturgy
> _...everything works right up until you need it, and has all the features
> you don 't want but none that you do._

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/](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.

------
Giorgi
I bet there are already projects in the making that will immediately claim the
cash prize.

~~~
codingdave
From their FAQ: "Applications must be new and built for the 2019 competition
between February 12 and July 29 2019, but they may use code that was open
sourced and available to all other participants as of February 12, 2019. Other
than that, almost anything goes, and you can use any coding languages or open-
source libraries."

------
psychometry
Stop subsidizing flood insurance for people who live in places that are
constantly underwater. Where's my check?

