#software #archiveapp-demo
While the theoretical framework of this paradigm is quite complicated, its application and goal are very easy to grasp.
As a developer, you want to create a solution to a real problem as software. It is not about creating software in itself. It is not that you create software that merely enables new actions, like tech demos, without any end in mind.
That means that the software in itself does not contain the solution. Take this app for example. It is a sophisticated plain text editor. It allows for fast actions. But the solution to knowledge work is the Zettelkasten Method. We think that The Archive is the best solution because we optimize it to fit this problem.
It is our job to understand knowledge work to its core and work on the method behind the software. It is more about the method than about the software.
Think about Getting Things Done. If you had to pick, would you rather have developed this method of self management or programmed an app? GTD spawned a plethora of apps but no app solves the underlying problem on its own.
- As a developer, you let the user pick the best software to solve a problem, not necessarily your own.
- Open formats enable collaboration between user inventions and developers.
- Domain knowledge and skin in the game are key to good decision-making.
Every problem already has a ton of software attempts at a solution. If you are honestly interested in the solution to a problem, you allow your users to choose their means, to pick which software they want to use and to switch with minimum effort.
Example: We believe that the plain text approach is the mightiest to store text. It enables maximal mobility of the user's data between different apps. With plain text, you can use the widest variety of apps and even operating systems.
This produces very basic rules:
- Save text as plain text.
- Save images as images.
- Do not use any storage system that differ from the files you want to store.
If software violates these rules it imprisons the user. That is not about solving a problem but locking-in users.
A good user is a good problem solver. The software should take this into account and allow user from different levels of expertise to contribute to the pool of problem solutions.
Example: Because we use a plain text data storage, you can easily manipulate your data with various script languages. That's why we plan to integrate a scripting interface into The Archive to speed this up. User who cannot code are still able to use and combine scripts by other people for a variety of use cases.
The fun thing is that both the user and the developer can learn from each other and work together on a solution. Usually, though, the situation ends with a powerless user sending in complaints to developers, and developers lacking the empathy to understand less experienced end users' demands.
Objectively, there are better solutions and there are worse. You can argue about some individual differences but that doesn't brush away the fact that some solutions are just plain better than others.
Good software contains not just features that users wish for. Sometimes, users are wrong. As a software developer, you have to be an expert not only in software development but also in the domain in which you try to solve a problem. That means: You have to have skin in the game to make good software.
Example: We are using a Zettelkasten over half a decade now. Sascha did extensive research on the subject of knowledge work and writes all day, every day. Christian is using the method for an even longer period of time, albeit less intense than Sascha. He has to code stuff like this app, after all. We eat our own dog food. This experience and skin in the game gives us some authority to reject proposed solutions with a reason. It is rare that we are confronted with a proposal of a feature that we didn't already test to oblivion.
Of course you will make mistakes. But with skin in the game and the habit of learning about the topic, developers can more easily take ownership of the product and its coming-about. This results in the required self-esteem to say "No" to user requests and to admit when one has misjudged something.