What is a Feature?

I’ve written before about the adoption of decentralized technology being largely driven by the fact that users won’t ever care about decentralization alone and will need to understand the benefits first and foremost (not the tech). This is a constant thing I try to remind myself of and try to remind other developers of. Decentralization is not a feature.

Or, is it?

In a great conversation on Twitter, a couple of developers building on the Blockstack platform participated in a discussion of decentralization as a feature. It started with this tweet:

With good points made all around, it seemed important to look at what a feature is and how we judge features versus tools that enable features. Let’s start with the very basic definition of a software feature:

“A feature is a small, client-valued function expressed in the form <action><result><object>.”

This definition comes from An Agile Introduction. There are variations of this definition, but I like it because it maps out not just what a feature is but what it does for the user.

Based on the above definition, we cannot consider decentralization a feature. We might consider storing authentication information on the blockchain a feature. So, the action would be “Sign up”, the result would be a decentralization identifier being created and stored on the blockchain. And the object would be the user account that is now owned by the user.

Here’s another example. Storing an encrypted document on a user’s own storage hub. User-selected storage is a feature. Encryption is a feature. The action for those features is simply creating a document. The result is an encrypted file stored where the user asked it to be stored. The object is the document itself.

Both of the above examples are enabled by decentralization, but decentralization is not the feature. Decentralization is the tool. Much like a hammer and a nail aren’t features of a house but rather tools to help build features of the house, decentralization allows developers to build the features that add value to their users.

During the 90s dot-com boom, the feature of the boom wasn’t the web itself or the architecture of the internet that enabled the web’s growth. The feature for many sites was convenience. The web offered the tools to build those features. The way these sites were marketed surely used the idea of the web, but they pushed convenience over all else. The phrase “dot-com” grew to mean convenience. So, with that in mind, it is possible that saying something is “decentralized” will ultimately mean something else that is feature-driven, but until that time, it’s important not to get bogged down in decentralization as a feature and instead focus on it as a tool that enables the creation of features that previously did not exist.

At Graphite, the focus is on what makes a user happy. The word “decentralization” doesn’t make a user happy. Data ownership, speedy performance, helpful features make users happy. I may refer to Graphite as a “decentralized app” but that is much like the early 90s web apps referring to themselves as “online.”

Let’s keep the discussion going. Feel free to comment here or connect on Twitter!