Philosophy Mondays: Human-AI Collaboration
Today's Philosophy Monday is an important interlude. I want to reveal that I have not been writing the posts in this series entirely by myself. Instead I have been working with Claude, not just for the graphic illustrations, but also for the text. My method has been to write a rough draft and then ask Claude for improvement suggestions. I will expand this collaboration to other intelligences going forward, including open source models such as Llama and DeepSeek. I will also explore other moda...
Intent-based Collaboration Environments
AI Native IDEs for Code, Engineering, Science
Web3/Crypto: Why Bother?
One thing that keeps surprising me is how quite a few people see absolutely nothing redeeming in web3 (née crypto). Maybe this is their genuine belief. Maybe it is a reaction to the extreme boosterism of some proponents who present web3 as bringing about a libertarian nirvana. From early on I have tried to provide a more rounded perspective, pointing to both the good and the bad that can come from it as in my talks at the Blockstack Summits. Today, however, I want to attempt to provide a coge...
Philosophy Mondays: Human-AI Collaboration
Today's Philosophy Monday is an important interlude. I want to reveal that I have not been writing the posts in this series entirely by myself. Instead I have been working with Claude, not just for the graphic illustrations, but also for the text. My method has been to write a rough draft and then ask Claude for improvement suggestions. I will expand this collaboration to other intelligences going forward, including open source models such as Llama and DeepSeek. I will also explore other moda...
Intent-based Collaboration Environments
AI Native IDEs for Code, Engineering, Science
Web3/Crypto: Why Bother?
One thing that keeps surprising me is how quite a few people see absolutely nothing redeeming in web3 (née crypto). Maybe this is their genuine belief. Maybe it is a reaction to the extreme boosterism of some proponents who present web3 as bringing about a libertarian nirvana. From early on I have tried to provide a more rounded perspective, pointing to both the good and the bad that can come from it as in my talks at the Blockstack Summits. Today, however, I want to attempt to provide a coge...
>400 subscribers
>400 subscribers
Share Dialog
Share Dialog
Yesterday I read not one but two separate posts about removing features from products (sorry - no links right now as I am on BB only). This is a crucial topic for any software product / web service. In the physical world there are limits to creating monstrosities by piling on too many features. Buildings will collapse if you add too many floors to the top. Planes won’t fly if you load them up with too much stuff.
In software the only limits to complexity appear to be what the developers can wrap their minds around. That is generally way more than endusers can stomach. Especially on larger products where individual developers have a bit of “the elephant is a …” experience from working on one part of the service, whereas the enduser needs to deal with the entire elephant!
So in the absence of physical constraints on featuritis, where can restraint or even removal come from? For one-developer projects the answer is easy. But the second you have more than one person involved it gets much harder: “Hey, that’s *my* feature - I spent xx hours building that.” Usability testing will be a great help - but ultimately it is critical to have a product or design lead who can act as a benevolent dictator.
Yesterday I read not one but two separate posts about removing features from products (sorry - no links right now as I am on BB only). This is a crucial topic for any software product / web service. In the physical world there are limits to creating monstrosities by piling on too many features. Buildings will collapse if you add too many floors to the top. Planes won’t fly if you load them up with too much stuff.
In software the only limits to complexity appear to be what the developers can wrap their minds around. That is generally way more than endusers can stomach. Especially on larger products where individual developers have a bit of “the elephant is a …” experience from working on one part of the service, whereas the enduser needs to deal with the entire elephant!
So in the absence of physical constraints on featuritis, where can restraint or even removal come from? For one-developer projects the answer is easy. But the second you have more than one person involved it gets much harder: “Hey, that’s *my* feature - I spent xx hours building that.” Usability testing will be a great help - but ultimately it is critical to have a product or design lead who can act as a benevolent dictator.
No comments yet