4 ms·

Sheets seems like a good way to get to a MVP quickly to prove the concept. If Sheets starts falling over due to demand, you know you've got a winner and its ti

by ENOTTY 6y ago

Sheets seems like a good way to get to a MVP quickly to prove the concept. If Sheets starts falling over due to demand, you know you've got a winner and its time to invest in something more reliable.

arkitaip 6y ago
Not everything is a MVP ready to disrupt. Sometimes all you have is a spreadsheet with data that lots of people have a fleeting interest in.
- toomuchtodo 6y ago
  A spreadsheet is a database you haven't yet performed a migration on yet. I think the argument is less around better spreadsheets and more around migrating that data into real datastores once constraints are encountered (whether that's a desire to support large amounts of contributors, not run on Google, the dataset has grown too large, etc). It's hard to go from Google Sheets to a web frontend to Postgresql and a snappy shared frontend. That is the problem statement to solve for imho (interface, schema, data portability).
  - PeterCorless 6y ago
    No one has really solved the "Spreadsheet —> Database" migration painpoint. We don't have anything that is universally easy-to-use. The equivalent of a Hypercard or a Filemaker for the Web. (And no, I'm not talking about MongoDB or other NoSQL; I'm talking about the kind of thing you can hand over to a typical office worker.)
    - toomuchtodo 6y ago
      Agreed. I have a hunch that any solution to this problem will look similar to https://github.com/simonw/datasette https://github.com/simonw/datasette if it develops. Tied together with https://supabase.io/ https://supabase.io/ and you've built a versatile, powerful, open data collaboration engine.
ISL 6y ago
The tricky part is the timescale. For a crisis-response, an approach may reach maximum impact within days and really only be needed for a short duration (a week to a month). Migrating a system with intense user/volunteer churn (and keeping two databases synced as you transition) can be tricky. Handling permissioning at the same time is also a challenge. At FindTheMasks, we expected the government to have supply chains and epidemiological response (testing/contact tracing) together within two or three weeks. When that didn't happen, we kept bolting on new tools and strategies to double the lifetime of the endeavor, expecting the government to get its poop in a group by then. 20 weeks later, supply chains are somewhat improved, though the entire situation is compromised by the lack of overwhelming success at the epidemiological scale.

by ENOTTY 6y ago

Sheets seems like a good way to get to a MVP quickly to prove the concept. If Sheets starts falling over due to demand, you know you've got a winner and its time to invest in something more reliable.

arkitaip 6y ago

Not everything is a MVP ready to disrupt. Sometimes all you have is a spreadsheet with data that lots of people have a fleeting interest in.

toomuchtodo 6y ago
A spreadsheet is a database you haven't yet performed a migration on yet. I think the argument is less around better spreadsheets and more around migrating that data into real datastores once constraints are encountered (whether that's a desire to support large amounts of contributors, not run on Google, the dataset has grown too large, etc). It's hard to go from Google Sheets to a web frontend to Postgresql and a snappy shared frontend. That is the problem statement to solve for imho (interface, schema, data portability).
- PeterCorless 6y ago
  No one has really solved the "Spreadsheet —> Database" migration painpoint. We don't have anything that is universally easy-to-use. The equivalent of a Hypercard or a Filemaker for the Web. (And no, I'm not talking about MongoDB or other NoSQL; I'm talking about the kind of thing you can hand over to a typical office worker.)
  - toomuchtodo 6y ago
    Agreed. I have a hunch that any solution to this problem will look similar to https://github.com/simonw/datasette https://github.com/simonw/datasette if it develops. Tied together with https://supabase.io/ https://supabase.io/ and you've built a versatile, powerful, open data collaboration engine.

ISL 6y ago

The tricky part is the timescale. For a crisis-response, an approach may reach maximum impact within days and really only be needed for a short duration (a week to a month). Migrating a system with intense user/volunteer churn (and keeping two databases synced as you transition) can be tricky. Handling permissioning at the same time is also a challenge. At FindTheMasks, we expected the government to have supply chains and epidemiological response (testing/contact tracing) together within two or three weeks. When that didn't happen, we kept bolting on new tools and strategies to double the lifetime of the endeavor, expecting the government to get its poop in a group by then. 20 weeks later, supply chains are somewhat improved, though the entire situation is compromised by the lack of overwhelming success at the epidemiological scale.