I have recently been thinking very carefully about the value of software.

Edgecase was in part an experiment to see if it could be possible to sell software by itself, rather than as a component in a product. I reasoned that if software alone could be a product, perhaps in the future it might be worth producing high-quality software. Software actually worth writing carefully and with craftsmanship. Leading, perhaps, to a world in which it was worth undertaking the arduous journey of shaping yourself into a software craftsman.

By "software", I am referring to source code, not compiled binaries.

I think I have now accumulated enough experience to finish this experiment, and to conclude that the answer is no. Software cannot be sold as a product.

I can say this because I have concluded that:

Software does not have value.

I can go further.

Software has negative value.

Every line of code is a liability.

Every line, every character, every bit is a potential hour of future programmer cogitation, as soon as the software requires maintenance.

This cogitation costs energy, joules. Joules that must be paid for. Who will pay for them? And why?

If you pay someone, and in return they give you lines of code, you got a bad deal. You traded an asset for a liability.







Even if customers exist who are willing to pay for software, trying to sell it is a bad business strategy.

Software, once written, is a sequence of 1s and 0s, a bitstring. On a computer, it can be copied infinitely many times.

Value accrues to that which is scarce and desirable.

Software, once written and sold to a single customer, is not scarce, and cannot be scarce, because of the nature of computer networks, which are constructed around the warp-speed copying of information from one location to infinitely many other locations.

Therefore, software, once written and sold to a single customer, has no value, even if it is desirable. A single client can buy your software and sell it to the entire world for a lower price than you charge. One of his clients can then do the same thing to him, and so on repeatedly until the market price of the software is 0.

This is why I can say that:

Software does not have value.

And, once the inevitable future cost of maintenance of the software is taken into consideration, it becomes clear that:

Software has negative value.







Software that exists only in potentia, as yet unwritten, has some value. Some problem exists, a solution to it would be valuable, this solution could in theory be implemented in software, and therefore it is worth considering paying someone to write this software.

Therefore, I can conclude that:

The future time of a programmer has some value.

Now, programmers vary in skill and experience, but programming skill is notoriously hard to evaluate.

If a customer cannot distinguish a good programmer from a bad one, then it is not worth paying more than the average price for a programmer. Programming skill becomes a lemon market, in which good programmers cannot demonstrate their quality to potential clients, and therefore can never charge more than the average price. Thus, on average, programmers will mostly not try very hard to improve their skill more than is necessary, because doing so is not particularly rewarded in the market.

Edgecase is in part a means for me to build a reputation that is significantly better than average. No sane person would have gone to the trouble of building their own private blockchain for publishing from a purely financial point of view, but to have done so is a rare (and public!) demonstration of skill and experience.

I conclude that:

The reputation of a programmer has some value, because it can permit a client to rationally choose to pay a premium for that programmer's future time.







Why pay a programmer to produce software?

Or rather, why does a potential piece of software that could be written have any value?

The answer is: There are classes of problems in the world. All of them involve manipulating the flow of energy, which originates in the stars and terminates in the deep black endless expanse of space. Along the path of this energy flow, some solutions to these problems can be bought and sold in a market.

If a problem can be transformed [0] into an information-processing problem, and appropriately mapped and described, software can be written to solve this problem to a some satisfactory degree. It is often energetically cheaper to solve a problem in terms of information rather than in terms of physical activity. If, for a particular customer, this solution is actually cheaper than whatever he is currently using, then it is worth purchasing.

Anything that improves the efficiency of energy flow is worthy of consideration. It may even permit the pursuit of greater energy capture, rather than just a reduction of energy costs, by making certain activities possible that were once too difficult to undertake.

For so long as a particular problem is relevant, and there are customers who can improve their energy efficiency by using a software-based solution for this problem, it may be possible to run a business model that develops and maintains a software-based solution and captures some of its value.

I conclude that:

A programmer's future time has value if and only if this time is used to build and maintain a profitable software-based solution to a problem for which there is a market of paying customers.







What profitable business models can be constructed around software-based solutions?

Value accrues to that which is scarce and desirable.

What is scarce and desirable?
- Time
- Access
- Convenience
- Energy
- Reputation
- Customers
- Skill
- Experience
- Property
- Currency
- Political Influence
- Military Power
- Security
- Status
- Profit

So, any software-based solution that helps customers gain anything on this list could potentially support a profitable business model.

Examples:

1) A server-based API that performs some useful functions. Access to it is paywalled or partially paywalled. This business model is built around Access.

2) A customer-relationship-management (CRM) web application, that permits its customers to record and manage information concerning their own customers. It's probably not possible to provide this as a standalone client application, because then it would just be software, a bitstring, infinitely copiable and of no value. However, it might be worth paying a programmer to write a client application that interfaces to the server backend, purely to improve the customer experience of interacting with the server. This is an instance of (1), but with a graphical user interface (a GUI) on top. This business model is built around Convenience and Customers.

3) A messaging system, that allows its customers to communicate at great distances, without having to physically travel to meet each other. Perhaps the system is offered to its users for free, in which case the actual customers are advertisement agencies. This business model is built around Convenience.

4) A cryptocurrency, such as Bitcoin, whose operators (miners) charge its users (via transaction fees) for making secure financial transfers. This business model is built around Currency and Security.

5) A secure messaging system, built on public-key cryptography, that allows its customers to communicate securely, at great distances, without having to physically travel to meet each other. This business model is built around Political Influence and Security (and Military Power, as soon as the market in ransomware components becomes sufficiently mature).

6) A online document archive, where the documents are free to access, but a search application (custom-built for this archive) is paywalled. This business model is built around Time and Convenience.

One can argue about the different business models and what exactly they are built around, but what is undeniable is that none of them are built around Software.







Why does software require maintenance?

Why shouldn't it just run forever, for as long as the hardware lasts? Maybe even longer, if replacement parts are available?

Well, software is essentially a phonograph that replays the voice of the programmer, and makes his decisions again in his place. It is an idiot clerk, a robot, a clockwork piano.

These decisions will be made within some domain - some region within the physical world.

This region does not have to be outside the computer. It can be contained entirely within the computer's circuitry. Many games fall into this category.

So long as this domain does not change, the programmer's past decisions will remain relevant. But, if the domain does change, even a little bit, the recorded decisions and their relative weighting will begin to desynchronise from the domain. The software will become less and less competent at resolving problems within the domain.

Why would the domain change?

The answer is:

Reality is infinitely complex, raw chaos, void of permanent structure, endlessly twisting and turning, falling in upon itself, and bursting out again with new energy. Here and there, temporarily, patterns emerge, tempting observers with their regularity, their potential predictability, the chance to know the future, or at least to accurately estimate it. Sometimes patterns perpetuate themselves for a long time, from the subjective viewpoint of the observer. But any perceived permanence is illusory - no pattern lasts forever.

So: The environment around a particular domain will shift over time. In a sense, it will begin to exert a gravitational pull on the domain. Eventually, the domain will be forced to warp and stretch, and any software that replays decisions for this domain will become less and less accurate.

Example: An accounting software package. A business purchases it. The business exists in some jurisdiction. The accounting rules in this jurisdiction will alter over time, due to changes in the jurisdiction's various aspects (political, cultural, technological, etc). Gradually, the software's decisions and assumptions, constructed under different accounting rules in the past, will desynchronise from the accounting rules in the present. The software will now require maintenance (patches, new recipes, different ways to use it that were not originally planned ("hacks")) in order to better synchronise it with the present.

This is not all, however.

Software is not infinitely maintainable. It will have certain basic assumptions, whose implementation will form the core of its internal structure. Eventually, even these core assumptions will become desynchronised from the outside world, and it will become cheaper, often much cheaper, to throw away the software and write a replacement from scratch.

As the desynchronisation of core assumptions from reality occurs, the software will become harder and harder to maintain. The decision to throw it out and start over is necessarily a judgement call. [1]







Does software quality matter?

Software has no value. It can't be sold. Why write good software?

Well, "low quality" in software generally means "rapidly becomes hard to maintain and use".

In what circumstances does it make sense to pay for higher-quality software? I.e. pay more, rather than buy cheaper, lower-quality software?

I think the answer is: If someone runs a business, and plans to run the business for a long time in the future, then it makes sense for them to invest in high-quality software for the internal processes of the business. The software itself cannot be sold, but it can allow the business to sell more of its actual product, to improve the quality of the product, or to produce the product more cheaply. If the software is higher quality, its lifetime will be longer, its accuracy will be greater, and its maintenance costs will be lower. It will always, however, be a liability, and only worth considering if the alternatives are worse, or more expensive.

Externally, the business's customers do not care, at all, about the software used within the business. The customer cares about finding a solution to his problem. The only external value, from the point of view of the customer, is the promise of the business to deliver a solution to the problem over some time period (e.g. that a server API will be available with 99% uptime during the subscription period, or that a computer will continue to function for some particular lifetime after it was purchased, etc).

Today, due to the warp-speed communication properties of computer networks, every business is involved with software to some degree, and will often need to consider commissioning custom software to handle some internal process.

I conclude that it is best for a business to:

1) Forget about software quality for its own sake.

2) Focus on a very specific problem. Focus on designing and building a solution to this problem.

3) Invest in software quality only to the degree that it profitably improves the quality of the actual solution as experienced by the customer, over the lifetime of the company.

4) Be willing, eventually, to throw out the software when the cost of maintaining it becomes greater than the cost of commissioning a new implementation.

I conclude that it is best for a programmer to:

1) Focus on understanding the domain of the problem that the business solves.

2) Produce as little software as possible.

3) Avoid prioritising software quality if the software is not crucial, will not have a long life, and/or will not be used intensively. In these cases, the higher initial cost of construction of high-quality software will not be worth it.

4) Understand that all is transient, the software that you write will probably not last your lifetime, and that it is philosophically impossible to write perfect software. It will always eventually begin to die, once the environment shifts enough.







Should a programmer ever write and publish software for free?

I can think of several reasons to do so:
- to practice a particular programming skill
- to establish a reputation
- to commission, from himself, for free, a solution to a problem that he wishes to solve

However, to expect financial reward from this is madness. The only ways in which to benefit financially are:
a) use the reputation to get paid work from existing businesses
b) to start a business built around the particular problem that he focused on solving

If you are writing software, for free, and publishing it, for free, and you aren't planning to pursue (a) or (b), and yet you expect financial reward from this course of action, you will be sorely disappointed.

Some notes:
- Donations-for-support are a special (and usually less profitable) case of (a).
- Don't worry about people taking your published software for free, instead of buying an instantiated solution from your business. They're getting a liability, not an asset.