Wednesday, June 21, 2017

Sorry for the low blogging throughput...

Dear Blogspot,



While working the other day, I was watching the throughput meter in a downloader/patcher as it moved about a gig of data from the internet to my hard drive.  The meter was showing me how many bytes per second I was downloading.  There was also a wonderful little widget for limiting the throughput.  I could choose options from 64 kilobytes per second all the way up to 4 megabytes and Unlimited.  It is this widget and how it works that I'd like to tell you about.

I'm sure the algorithm used to produce the above graph is more clever, but the most straight-forward network rate limiter basically works by:

1. Observing a maximum throughput (how many bytes have come in lately?)

2. Extrapolating future throughput over a set time period (at this rate, how many bytes will I download by the time 1 minute has passed?).

3. Pausing, by simply refusing to read, the incoming traffic until new extrapolations of the future throughput match the desired throughput.

4. Repeat

For example, suppose I cannot help but eat one peanut per second, for an expected maximum peanut throughput of 60 peanuts per minute, but I only want to eat 20 peanuts per minute.  The way to accomplish this would be to tape my mouth shut and bind my hands for 2 full seconds for every 3 seconds available, so that only once every 3 seconds am I actually able to eat a peanut.  Since my normal eating rate is one peanut per second, by preventing me from getting at the peanuts 2/3 of the time, I have successfully reduced my peanut consumption throughput to 20/minute.

If you were to graph my throughput-limited peanut-eating, it would look like this:


Peanuts are a good analogy because, like network downloads, the receiver has little to no control over the size of each incoming package of data.  This limits the receiver (or peanut eater) to either consuming or not-consuming.  Partial-consuming is not really an option.  This leads to very jagged graphs, as you see above, because consumption is always followed by deprivation in order to control the overall throughput.  And even if one could somehow eat 1/3 of a peanut per second (try it, it's not easy), that would definitely not work for download data, since there is no way to ask a transmitter to only send a partial byte per packet.

So, what has surprised me in the past is how alarming a graph like the above can be to folks.  Why can't an accurate graph of limited throughput be smooth?  When I want to limit my rate of walking, I don't walk normally and then pause every second before continuing to walk for another second.  I just walk slower, in one fluid motion.  Why can't the graph be like that?

Well, the graph can certainly LOOK like that, if one, for example, graphs the median throughput over a period instead of the actual bytes or peanuts consumed during each atomic unit of time.  But that wouldn't quite be the truth about what is going on.  It would be covering up the mechanics of reality with statistical lies.  It would be pretending that something happened during an atomic unit of time that really didn't happen at ALL.  I once wasted an hour trying to explain this to some folks, and that didn't go well.  They just wanted the data to be slower, and not pause all jaggedy like that.

The size of each package of incoming peanut or data, and the limited ability of the receiver in how they can react to incoming peanuts and data, dictates both the algorithm one must use to limit data, and the way an accurate graph of data throughput over time would look.

All that said, my advice is this: screw accuracy; don't try to explain or show any of this to anyone.  Just use a smooth-averaging algorithm to hide the jagged edges of reality when making your throughput graphs.  It's much easier to do this than to try to explain why those toothy fangs are more accurate.  Besides, the graph is meant to convey a general rate of data, not provide a window into actual data movement along your i/o bus.


Sunday, December 22, 2013

Remy's "All I Want for Christmas is U..." Explained

Remy has a new song for reason.com, which you can see here:

http://reason.com/reasontv/2013/12/20/all-i-want-for-christmas-is-u-remys-fisc

For my sister, and my own amusement, here are the lyrics, with commentary:

I don't want no eggnog, lactose ain't for me
I don't need new pants.  Then again…TBD…
Don't want any gifts this Christmas it's true
all I want for Christmas is...
I don't want a Surface tablet, that one's pretty clear
I don't want that new book by Martin Bashir
[The book "Catch 1 & 2" showing a cop and a toilet is a totally made-up book, but the author is a real MSNBC commentator named Martin Bashir, who apparently got suspended from the network by talking about some really crude slave punishments involving defecation, and suggesting Sarah Palin deserved that punishment for her views.]
There's only one this I want, yes it's true
all I want for Christmas is U…..
...nilateral printing of billions of dollars
a month to be stopped cuz it's causing my dollar to
rampantly inflate
[Price Inflation is caused by more dollars being in the economy vis-a-vis goods available to purchase.  We often talk about inflation in terms of the prices of stuff, but since the cause is always monetary, it is also correct to talk about the dollar itself "Inflating".  
For example, suppose a candy bar costs $0.50. Then one night all of the US Dollar bank accounts on Earth are doubled, so everyone has twice the dollars they used to have.  However, the number of candy bars did not double.  Therefore, using simple supply and demand, we would see the price of candy bars get bid up to $1.00, which would be its new price going forward.  So people have more money, but are really no better off, since all the prices double too. ]
, I tell you it's killing us
all of this open-ended fiscal stimulus
["Fiscal Stimulus" means spending by the government.  Since governments are funded by taxes, it might seem weird to talk about it during a diatribe about inflation, which is caused not by taxes, but by newly created money.  However, governments are also funded by borrowing.  The way the U.S. borrows money is by issuing Treasury Bills (hereafter "T-Bill"), a kind of government bond.  You buy one from the U.S. government, and then, after some period, the government pays you back principle plus interest. The Federal Reserve System (hereafter "FED") has been buying lots and lots of T-Bills using newly created (inflationary) dollars.
So, Remy here is suggesting that the "Stimulus" packages, which were just weird random multi-multi-billion dollar government spending bills, were being funded by FED inflationary policy, which is true.]
Risk underpricing and rampant inflation
resulting in capital misallocation
all I want this holiday season
is an end to quantitative easing
[Lots to unpack here.  So, from the above, you should understand why Remy believes there's a connection between "Fiscal Stimulus" and his fears of "Rampant Inflation", so I'll let that part be (by the way, why rampant inflation hasn't arrived yet is also an interesting subject having to do with FED policy and the general protracted sickness of the economy preventing all the new dollars from circulating).
"Risk underpricing" has to do with the effects of inflationary FED policy on interest rates.  Since interest rates are the price of borrowing money, when the FED creates more money, they cause interest rates to be lower (law of demand).  Businesses that borrow money for projects look closely at interest rates.  If their projects are "sure thing winners", they will care less about the interest rate, because they know that no matter how high the cost of the money is, they will be able to pay it back with the profits from their "sure thing winner project".  However, if their project is less "sure thing", then they may only borrow the money if the money is cheap, since they may be worried about being able to pay the loan back if the project doesn't bring in much profit and cause their whole enterprise to go bankrupt.  So this means that Inflationary FED policy causes businesses to take out loans for riskier projects by "underpricing" money, which Remy calls "Risk Underpricing".
"Capital Misallocation" refers to businesses engaging in riskier and longer-term projects due to the unnaturally low interest rates caused by FED inflationary policy.  "Capital" in this case refers to the dollars that businesses borrow for their projects, and "misallocation" means they are "allocating" those dollars to projects they would otherwise not engage in due to them being too risky or unprofitable, thus the "mis" part.]
Now Santa I know you get this a lot
those children's letters concernedly fraught
[You should slow down the video and read some of the letters to Santa.  I won't go into them, but they are funny.]
But I'll tell you what I want and save you some pains
I'll take the candy--you can keep the Keynes
[Keynes was a philosopher who, while never trained as an economist, wrote a book called "A General Theory of Employment, Interest, and Money" which transformed economic thought in the 1940s and 50s.   The aspect of his theory Remy is thinking about here is Keynes' idea that fiscal stimulus can cause underutilized/idle capital to be re-employed and "kick start" a slumping economy. We know what Remy thinks of fiscal stimulus, so naturally he wants nothing to do with Keynes.]
Presents under the tree, the Fed starting to taper
["Fed starting to taper" means that the FED has announced that it will buy fewer T-Bills in the future, thus slowing down its inflationary policy.]
Because only one of them should be covered in short-term paper
["short-term paper" is another way of talking about T-Bills, and has to do with the maturity date of the asset.  When you buy a T-Bill, you can sell it back to get your principal and interest back only after a certain amount of time, or by a certain date, called the "maturity date".  When a bond has a very short time period, it is called "short-term paper".  Most T-Bills are "short-term paper".  We discussed above how Remy is concerned about how the FED banks are buying lots and lots and lots of T-Bills to keep the U.S. government afloat, and risking inflation thereby. ]
Don't want nothing else for Christmas it's true
all I want for Christmas is U….
…uniformity in the mandate of the Fed
[When congress created the Federal Reserve (FED) System, they gave it three commands or mandates: Maximum employment, stable prices, and moderate long-term interest rates.  Many economists believe that those mandates are contradictory.  During an economic slump, employees are overpriced, so only lots of inflation can lower people's salaries (their price to the employer) in real-terms and make them affordable again.  However, inflation causes prices to be unstable, because inflation causes prices to rise.  The FED causes inflation by creating money which makes money cost less, which lowers long-term interest rates.  So on the one hand the FED is tasked with keeping money stable, and on the other hand it is tasked with creating lots of it to keep interest rates low.  Remy here thinks it would be better if they had a single non-contradictory mandate that it can actually accomplish.]
or reform the whole thing or start over instead
[Remy also thinks it would be OK to do more drastic things to the FED, though he didn't mention getting rid of it, so he is probably skeptical of free banking]
because I ain't a pro but I really don't think that
it's "Buy CDO's with some dough from an Inkjet"
[During the 2008 crisis, the housing-related financial products that were revealed to be worthless were called "Collateralized Debt Obligations".  Part of the U.S. Govt's policy of bailing out the banks and wall street was having the FED purchase those worthless CDOs with more inflationary money-from-nothing (or, as Remy says, from an Inkjet Printer) so that the banks that were holding them didn't have to deal with their own stupidity and capital mis-allocation.]
The year home run records were obliterated
that was the last time we saw Bonds so inflated
[I'm not really sure here, but the "year home run records were obliterated" was the late 1990s, which was during the dot-com boom, when there was also a Bond-bubble, so I think that's what he means.]
all I want this holiday season
all I want this holiday season
all I want this holiday season
is an end to quantitative easing.
That's all.  Hope you enjoyed this commentary, and Merry Christmas blogspot!

Saturday, May 11, 2013

Economic Lessons Learned

Dear Blogspot,

I know this is incomplete, and necessarily simplified and shortened, but I was recently inspired to jot down the most important things I've learned from studying economics.  So here it is; I hope you find it useful or interesting.



  • Self-interest drives human choice, but self-interest is not the same as selfishness.  We love our self image, our families, our friends, our neighbors, our God(s), our causes, and other things, and see it in our self-interest to preserve and promote them.  The only thing this principle precludes is a love of unknown strangers that is not expressed in terms of a more dear interest (such as furthering our causes, or promoting our self-image).
  • Incentives matter, a lot. Incentives are not always or even usually about money, however.  In fact, often non-monetary incentives can overwhelm monetary ones (such as every time we give up having more money in order to buy something).
  • Supply measures the incentives of producers, and Demand measure the incentives of consumers, though, in a way, Supply and Demand can both be reduced to asymmetric Demand.
  • There Aint No Such Thing As A Free Lunch (TANSTAAFL).  Everything comes at a cost.  Sometimes the cost is obvious, such as price tags, but there is also the cost of putting yourself in the position to engage in a transaction in the first place (transaction cost), as well as the sum of all alternatives we give up when we finally make a choice (opportunity cost).
  • Trade is always made of Win.  When people voluntarily exchange, it is because they both believe they are made better off in end, otherwise the trade would never happen.  It doesn't matter if trade happens between neighbors, cities, states, or nations -- trade is always made of Win.
  • If someone happens to be more skilled in every way at something than another person, they are still better off if they do what they are best at and then trade. This is the law of comparative advantage.
  • Think at the margin; think about the consequences of the next unit, the next time period, the next available option.  Life comes at you one choice at a time, so be sure to account for the margins of life.
  • Profit is the difference between how consumers value what is produced, and the cost of producing it.  Higher profits cause competition for a piece of those profits, and competition drives down costs to the consumer (prices).
  • Private and voluntary wages measure the value that society places on what we do to serve them.  If you want higher wages, increase the relative value of what you do for society.
  • Strong property rights, freedom of contract, and bourgeois virtue creates markets.
  • Markets are the system of voluntary production and trade.  They are a process by which self-interest is turned into social service, allowing us to serve the needs and desires of those otherwise precluded from consideration due to our self-interest. This is the "invisible hand".
  • Prices measure value, and people value things asymetrically and subjectively.  There is no such thing as a "right" or "just" market price, there is only the meeting place of supply and demand.
  • Leisure is a consumption good like any other, and goods are valued subjectively.  Lazy people who consume more leisure are exercising a choice to avoid some amount of the benefits of trade.  Such people shouldn't be scorned for this valuation, but they shouldn't be rewarded for it either.
  • Prices aggregate information about scarcity, desire, technology levels, fads, droughts, disasters, discoveries, inventions, alternatives, and more.  They aggregate a million details of specific time and place that no one person, or computer, can possibly know.  This is why economic planning without market prices does, and will always, fail to meet human needs.
  • Economies grow only when they produce more of what people want and need.  Demand is the goal of growth, not the cause, and there is no other kind of "growth" except increased value production.  Things that cause economies to grow include: a) more people, b) more capital, c) technology, d) organizational innovation, e) more skills.
  • Economics is the art of asking "And then what?".  Always consider the secondary and long-run effects of your actions.
  • Most of what economics has taught me is very unintuitive. "Thinking like an economist" takes practice, and probably a younger mind than mine to be trained that way.


Sunday, March 17, 2013

Major Economists, for Beginners


Major Economists, for Beginners:

- Adam Smith: Markets are a wealth machine cranked by invisible hands.
- John Malthus: Markets are the process by which WE ALL DIE AND GO EXTINCT.
- Karl Marx: By 1870, one guy will own everything, and capitalism will be dead.
- J.B. Say: We make excess stuff to exchange for other people's excess stuff.
- David Ricardo: Just do what you're best at and quit worrying about it.
- Carl Menger: What's it worth to you to find out what I think it's worth?
- J.S. Mill: The cost of something is not only what you paid, but all that you gave up.
- Alfred Marshal: Face it, if I double the price of B.B. ice cream, you'll still buy it.
- Leon Walras: In this equilibrium model, noone is doing anything any more.
- Thorstein Veblen: You just bought that so I would see you buy that.
- W. H. Phillips: Your choices are: Inflation, or Unemployment.
- L. von Mises: Umm socialists?.. you can't get there from here.
- Irving Fisher: You will gladly pay me Tuesday for a hamburger today.
- F.A. Hayek: Markets are far more informed than those moron economists.
- J.M. Keynes: Markets are about emotional outbursts soothed with shiny baubles.
- Ronald Coase: What Mill said, but THINK ABOUT IT THIS TIME.
- M. Friedman: If *everyone* has more money, things will just cost more.
- J.K. Galbraith: General Motors, Inc. will eat your children and control us ALL.
- Paul Samuelson:  If you're c/d+8e-k*ln(4/3) and you know it, read a textbook!
- James Buchanan: Bo just wrote all this because he's a self interested bastard.
- R.J. Barro: Go ahead and buy it, congress -- the kids will pay for it when we're dead.
- Robert Lucas: I see what you did there.  We all saw it.
- Gary Becker: A criminal is a rational economic agent, just like college students.

Tuesday, December 18, 2012

The Risk of Bugs

Dear Blogspot,

I've lately been thinking about how economists view risk, and how that analysis can help us think about software testing.

Economists refer to risk in a rather ordinary way, such as talking about the risk of getting into a car wreck, the risk of a particular stove causing a fire, the risk of being killed by Dracula, or the risk of your house being flooded.  A "risk" then is some unhappy event that we wish to avoid, since we find it in our interests to be happier rather than more unhappy.   Risk-mitigation is an economic "good", something we value and pursue.

Economists approach choices in risk-mitigation the same way they approach their analysis of choice regarding any economic good -- subjectively and marginally.  Those all-important economic terms mean that each person might have a different tolerance level for risk (the subjective part), and that we weigh each risk-mitigation opportunity according to the cost of obtaining it (marginal cost).

Because of this, economics rarely predicts a zero-risk situation where people are involved.  There are many reasons why.  The first is a knowledge problem: every possible risk is not instantly obvious.  The world is a complex place, and lots of unpredictable things happen.  The second reason was alluded to earlier, that some risks are just too costly to eliminate given our subjective preferences.  For example, we might worry about the chance of a meteor falling through our ceiling and striking us on the head while we sleep, and calculate that the only way to be completely safe is to live deep in the roots of a tall mountain.  The last reason is that the desire for safety from risk is unbounded.  For example, if we get ourselves a new robot, and find that it is homicidal, we might worry a lot about being killed and have it reprogrammed with the "Three Laws" to prevent that.  Afterwards, however, we might start worrying about it breaking our dishes while trying to clean them, and have its metal hands padded.  After that, we might eventually even worry about running into it in the dark and stubbing our toe, and so forth, and so on.

As you might have guessed, this exact same analysis can be applied to flaws in the implementation of a specific software design, commonly called a "bug".  A user encountering the effects of a bug is definitely an event that they wish to avoid, and (for various reasons) that we as engineers do not wish to introduce.  Software houses typically employ QA to try and discover these flaws before a user finds them, so that they can be fixed.  Other mitigation practices, such as Test Driven Development (TDD), unit tests, test automation, and so forth are also used to prevent users from encountering bugs in their software.

However, blogspot, I would argue that pursuing a zero-bug situation is neither wise nor practical, for all the same reasons mentioned previously.  Modern software systems are complex interactions of many different systems, and user interactions with software can introduce further uncertainty, making the task of even predicting every possible bug all but impossible.  Further, sometimes a bug is just too expensive to fix.  You may get a bug that the software is unable to handle data buffers larger than any reasonably available storage devices, which is something no reasonable engineer would fix.  On the other hand, we may discover a bug that has a very low impact on the user, and low chance of occurrence, but discover that it will take hundreds of man-hours of engineering to correct it, making such correction too costly to pursue.  An example of this might be that your software is vulnerable to a flaw in a specific model of video card that changes the visible shade of red slightly, and that the cost of writing code to detect and work around this hardware flaw isn't worth a slight color difference.  Lastly, the desire to be free of bugs is irrationally unbounded.  A quickly fixed bug that causes the software to crash on boot-up is an easy call, but eventually one would start worrying about software flaws that occur only when in certain rare hardware environments -- it would never end.

Well, blogspot, that is all I have to say on this subject.  As in my other posts, I would encourage my fellow engineers to think about our problems in the same way we actually end up making them: by weighing the costs and the benefits of each choice.  Demanding a zero-bug software product may make one seem bold and principled, but is only a way to set oneself up for disappointment, while simultaneously foregoing time that could have been spent on new products or more important improvements to existing ones.

Sunday, July 22, 2012

The Law of Comparative Testing

Dear Blogspot,

Two hundred years ago, David Ricardo taught the world about the Law of Comparative Advantage.  It states that any two nations, groups, or persons who have differing relative productivity in the production of different goods always benefit from engaging in their most relatively productive activities, and then trading the produce thereof with each other.  It is a direct challenge to protectionism on a national scale, and self-sufficiency on a personal one.

This principle applies to the software world rather clearly when one considers the role of Developer and Tester (usually called Quality Assurance or "QA").  To explain both what the Law is, and how it applies to our subject, consider the following example:

Suppose a Developer is capable of producing 10 units of application code every day, or capable of reproducing 9 bugs per day.  Suppose further that a Tester is capable of producing 1 unit of application code every day, or capable of reproducing 5 bugs per day.  No matter who finds the bug, the Developer will have to produce more code to fix it, but we still generally consider Found bugs to be a good worth pursuing. Now consider all the possible scenarios:

  1. The Developer and the Tester only spend their time reproducing bugs: 
    1. 0 units of application code is written, and 14 bugs are found every day (but found in what?).
  2. The Developer and the Tester only write code: 
    1. 11 units of application code is written, and 0 bugs are reproduced (wheeee!).
  3. The Developer only reproduces bugs, the Tester only writes code: 
    1. 1 unit of code is written, 9 bugs are reproduced. (That is the safest program never released!)
  4. The Developer and the Tester write code half the time, and find bugs half the time: 
    1. 5.5 units of code written, 7 bugs found. (Serious context switching going on here)
  5. The Developer writes code full time, the Tester finds bugs full time: 
    1. 10 units of application code is written, 5 bugs are found and reproduced.
  6. The Developer writes code and tests half the time, while the Tester tests full time:
    1. 5 units of code written, 9.5 bugs found.

As you can see, the mixture of activities that produces the most code and the most found bugs is number 5, which should also be what any actual developer and tester should intuitively conclude.  Note that this is despite the fact that, in the example, the Developer is better at both writing code AND finding bugs! Many would dispute the productivity in finding bugs that I have assigned to my Developer, pointing out that "clear" or "white" box testing is generally inferior to black box, as knowledge of inner-workings can bias the production of test cases.  Fair enough, but that would only make the case more stark in favor of testing by Testers.


Another adjustment you might make to the example would be to calculate productivity not by units of time, but by dollar units in costs.  Since Software Development is, in the current market, a more scarce skill and in higher demand than Testing, it tends to cost more.  If the same test were run using dollar units, the results would lean even heavier towards the employment of Testers for testing in Software Engineering.

So, Blogspot, why would such an obvious argument even need to made?  Well, just as protectionism and self-sufficiency arguments crop up all the time in debates about international trade (witness the witless discussion of U.S. Olympic Team uniforms in 2012), they are starting to creep into discussions about methodology in Software Engineering as well. And for the same reasons, these discussions should be nipped in the bud, before it starts to mean less and more expensive software on the market for the rest of us.

Thursday, April 12, 2012

The Political Economy of Software

Dear Blogspot,

In the parlance of economics, "Rent" is defined as money one makes on some product or service above and beyond the cost of producing it. Importantly, it refers to money one makes on something that is not destroyed during consumption, and where true ownership does not change hands, so that, having rented it to one person, it can be rented again. It seems to me Blogspot, that software is clearly an area where the money is clearly made through rents.

In subscription based software services, this point is pretty clear. A consumer pays a periodic cost for access to the software, the value of which disappears after the service contract ends. Traditional software also fits this bill. Since the marginal production cost of producing the next unit of software is zero, the software per-se can be thought of as a single good. From this perspective, we see that once "sold" to one person, an identical unit can be "sold again". The important thing, however, is that, at some point, the money made on marginal units is over and above the production cost, which makes it "rent".

But how does this affect the political economy of software production houses? Suppose a software company endeavors to produce one product, without any updates (yes, no place would do that, due to the increased sales and rents that come with making the update, but stay with me anyway). During production of that software product, the productivity of the designers, developers, QA, etc. is vital. They and their knowledge constitute the true capital of the company, and embody its value in future sales. Once the product is released, however, this productivity and knowledge offer diminishing returns. In a perfectly fluid market where every employee makes their local marginal utility at all times, salaries of these workers would drop, and some, perhaps all, would be laid off. In fact, were it not for the fact that knowledge gained during development constitutes important capital going into an update release, we could imagine the entire development profession being made up of temporary contractors.

Given our example, however, after release, the software house almost immediately becomes a building full of rent-seekers. Developers would immediately change their goals from productive software outcomes to that of convincing the owner that he or she warrants a cut of the continued sales of the program they produced (for which time they've already been paid). This is pure politics and shenanigans.

Now, stepping outside the thought experiment back into the real world, Blogspot, my point becomes this: Even if software houses DO plan updates, or DO offer subscription services, to what degree do these phenomenon show up anyway? Just because the marginal value of continued development is not Zero does not mean that it approaches the value of the work done to produce the first release. And to that degree, one would expect more rent-seeking behavior out of developers than before. The difference in expected productivity might change the nature of the behavior from (in the Zero value case) one of complete fantasy to (in the Normal case) one of exaggerated claims. However, the behavior would still be there.

How do those whose salaries are already tied to current and future sales (investors, owners, perhaps upper management) respond to this realization? Do they realize it at all? That I often wonder.

PostScript:
Of all my letters to you Blogspot, this one seemed the most "out there" to me.  Well, maybe not .. See page 23 of the leaked Valve employee manual:

The relevant quote is on page 17:
"Valve is not averse to all organizational structure—it crops up in many forms all the time, temporarily. But
problems show up when hierarchy or codified divisions of labor either haven’t been created by the group’s members or when those structures persist for long periods of time. We believe those structures inevitably begin to serve their own needs rather than those of Valve’s customers. The hierarchy will begin to reinforce its own structure by hiring people who fit its shape, adding people to fill subordinate support roles. Its members are also incented to engage in rent-seeking behaviors that take advantage of the power structure rather than focusing on simply delivering value to customers."