Economics at it’s very heart is the study of production, distribution, and consumption. Computer economics follow the same principals. The computer does very similar things it reads data, writes data, and calculates data. These activities are almost analogous, calculation is production, writing data is distribution, and reading data is consumption. Like real world economies we have fixed resources. We can view our computers as factories, and our programs as work-flows and logistical plans.
Factories in the real world have limits. They only have so many square feet, in which they can fit workers, machines, and resources. Our computers operate under the same principal that we are limited in our resources such as processor speed, RAM, network speed, etc. Part of programming is understanding how to work within these limitations.
Designing and programming applications that operate within the limits requires us to first to know, and then to understand a machines limitations. To know how fast an application will be processed we have to know how much time it will spend reading, writing, and processing.
Moore’s law has greatly alleviated this problem. We now have bigger, faster, and more efficient computers than we could have ever dreamed of, but that doesn’t mean we can ignore the bounds. We still need to understand which operations are expensive, reading data from a network location, compared to relatively cheap operations, such as incrementing an integer.
Even though modern computer hardware has greatly increased the resources we use, there are still areas where we must be vigilant. On example is, a web applications running on a server can easily be brought to their knees by a high user load. When developing web applications with a high usage these principals are not just helpful, they are required.
Once you understand the economics of the machine you can start to make intelligent trade offs for resources. One example is caching, a common strategy for reducing processing and data access by keeping a copy of commonly produced data in memory. These trade offs can have impacts, and create issues. Truly understanding the principals behind machine economies is very important.
Even though we should be aware of these principals, it is important to understand the real world trade off of time spent programming, and the need for software to ship. Many times we will release software that not terribly efficient on purpose. Maybe the time to develop was more pressing than performance, may be it is small web application that has a low usage. Whatever the reason we must accept that sometimes we must release software that is just good enough. That doesn’t mean we can be lazy as programmers, but it means that we should apply the principals of machine economics as we program, and know when we must hand tune our code.
