actual, verifiable digital ownership… using a distributed database technology that is designed to require a massive amount of computing resources to update.
I think where some of us who work in spaces using databases to verify something in critical business processes get stuck in accepting that blockchain has value is that our jobs have always been to verify “ownership” as quickly and efficiently as possible. We typically do this by defining a canonical source of truth and our success is judged on how many milliseconds transactions take and the datacener or cloud costs.
Saying that everything about blockchain is “dumb” isn’t a very nuanced analysis… but it’s a understandable reaction to hearing the hype that blockchain is going to change everything for years.
I’ve never seen anyone argue that the massively distributed nature or the public read access of blockchain technologies aren’t interesting. It’s the tradeoff that has to be made in speed and costs that make it hard for many of us to see any value in the approach for most applications.
Beware of the “whatever” aproach.
Many years ago I was brought into a project where many variables where named after cars. Before I got there, if the team couldn’t agree on a name, they’d use a car and move on. There was also a module in the code call “bucket”. Didn’t have a logical place to put a function? Add it to the bucket.
I’m sure they saved a lot of time not discussing what to name things up front, but by the time there was enough turnover on the team to change the variables and rewrite, it took months to fix.
Another, more product approach is to ask the “variable naming guy” to write up a naming policy document that would result in the names he has been suggesting. If there is logic associated his side of the “argument” it should be easy to document.
Have everyone on the team discuss and approve the policy. Hopefully you never spend time in a meeting arguing about this again.