A commodity is a basic good that is interchangeable with other goods of the same type.‌‌ Commodities are most often used as inputs in the production of other goods  or services.

From https://www.investopedia.com/terms/c/commodity.asp

Every software developer knows the joy of making a computer obey his command and successfully program its behaviour. However, that joy is not of the big difference from the farmer's delight reaping a corn harvest.


And in most cases - their products are commodities, and later they will be used as an input to produce something much more valuable than raw materials.


In my opinion, thinking that code is valuable by itself only because we are getting paid for it is a logical fallacy and a source of enormous confusion on where it would be better to focus while writing software.


The economy of scale, a cherished dream of all digital entrepreneurs, is not about scaling code as much as an art gallery is not about multiplying holes in the walls.


But where that value lies then? I firmly believe that it is concentrated in the model that code expresses.


Business creates a model within which a conflict significant for its customers is resolved. Let's call it a domain model. Then there is a model expressed by code. Let's call it a code model. The value of software lies within the code model, and the closer it is to the domain model, the more valuable it is.


It's as simple as understanding that adding a statement that establishes a connection to a database doesn't increase its value by another five euros.


A simple thought experiment: let's say we are building product X in Ruby, and at some point, we scraped a part of the code and rewrote it in C. How did that affect its value? We can assert that only by evaluating how well a code model is aligned with a domain model. Given that it stayed the same, only then we can account for other characteristics like performance increase.

So, what code model is? It's a construction that you build up in your mind while reading it, and it has its quality criteria like expressiveness, eloquence and clarity, to name a few.


The critical part here is to understand that your product loses value every time you dilute it by diverging from the domain model or trying to get away with abstractions provided by a framework or mixing infrastructural concerns with core logic, etc.

A good marker that you're on the right track is when bugs can be described in one or two sentences that make sense to a customer. I.e., they are caused by the incompleteness of the domain model, not by a code model being a thing of its own.