Computer Econ 101

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.

Diminishing Returns on Software Quality

Software production, like any other production, obeys the law of diminishing returns. Reducing flaws is part of the software production process so it also falls under this umbrella of diminishing returns. The law of diminishing returns states that when we add additional input into a production process we will see diminished output relative to the inputs at a some point. We can restate this in reference to quality analysis, the amount of time spent QA testing, writing unit tests, or other quality control measures will become less and less effective at reducing bugs and errors the more time is spent after a threshold of time spent.

An example of this would be a QA team is testing a section and they work 4 hours. They spent the 1st hour working and they found 8 bugs, they spend another hour working and only find 4 bugs, after the third hour of testing they found 2 bugs, and in the fourth hour they only find one more bug. We could say that the output diminished each hour they worked.

In the graph below you can see how the number of bugs starts to trail off. This would be an example of how after a certain time the output is decreasing even though more time is spent testing. In this example over 50% of the total bugs found would have been the first hour 80% by the second hour.

Bugs Per Hour Chart

Most often the initial QA testing is the most valuable, and then less and less bugs are found the more testing is done. This shapes the way we approach QA, and why many times QA is cut short, because reduction of flaws becomes more and more expensive, especially with larger products. This information also can shape how a testing process is developed, and how deep or shallow we choose to test each section.

Putting this altogether helps us as developers understand that flawless software is very difficult, and expensive to produce, because QA time becomes less and less effective after a certain threshold. The difficult part is figuring out when QA returns are diminished, and is there a point where it starts to drop off drastically? Every project, and every organization are different, and so this could very greatly depending on a number of factors, QA testers ability, software complexity, domain complexity, organizational factors, etc.

The law of diminishing returns as relates to quality and QA ties into the bigger picture of the project triangle (Scope/Quality, Cost, and Time). If we understand how much time it will take to reasonably test our software we can better balance the quality with deadlines and costs. We know that we may be able to shave 20% of a QA testing budget and not cut into the most valuable QA testing time and can more accurately forecast the risk associated with such a decision.

What Web Developers Can Learn from Assembly

300px-Half-adder.svgLearning assembly can provide a significant benefit for web developers. I recently began learning and programming assembly for the x86 processors. This is more of a refresher, since I had learned some assembly on the university VAX.  I consider learning to program in assembly some of the most important knowledge I have learned. Assembly programming taught me about how programs are processed, how memory allocated and used, and better understanding of modern computer architecture. These skills may not be directly applicable in high level languages, but it does allow us to understand the big picture.

Programming in assembly requires you to think in bits and bytes. You must allocate your own memory. You have to move data into registers and directly perform arithmetic and logical operations on bits and bytes of data, rather than just defining a for each loop and iterating through objects. Using assembly is in effect directly telling the processor which instructions to execute on which data. You learn how to do the heavy lifting rather than having a high level language do it for you.

Assembly programming can help shore up your knowledge of existing languages. One area where assembly is very effective is understanding memory management. Even though memory management is now handled by modern language with garbage collectors. In assembly we have to explicitly define how much memory we need. We may define 64 bytes for an array, rather than just defining a variable for a list and initializing the object without ever knowing how big that list is. Understanding how memory is allocated can help us minimize the overall foot print of all of our applications and be more efficient.

Beyond this experience with assembly allows you to experience how processing happens. How expensive it is to move things to and from memory and processor. How expensive and slow accessing non memory data such as disk or network resources. It gives you a better feel for bottlenecks in applications. This knowledge becomes extremely valuable when optimizing applications, and understanding how and when to make time and space trade offs.

Overall assembly programming showed me the whole picture of programming from typing in code, compiling the code, and finally running an executable.  This solidified many of the concepts I had learned, how algorithms work and why some are orders of magnitude more efficient, and how data structures are allocated and processed.  These higher level concepts directly improved my knowledge of programming in high level languages, and allowed me to make wiser technical decisions because of it.

Profile Picture

About Ian Lintner


I am a software developer, mostly web,  in Des Moines, Iowa. I take a very opinionated stand concerning development, you will never regret a simple design or architecture. My education was at Drake University in Biology and Computer Science. Offline I am recently married to my wife Heather. I try my hand at many hobbies currently I am gardening till the snow comes in.



My Current Projects


Des Moines Twitter Trends