The fallacy of assuming constant demand

schwern on 2007-06-07T14:22:35

As you may or may not know, there's a plan to make Test::Harness 3.0. The plan, AFAIK, is to replace the guts (Test::Harness::Straps, an experiment of mine which never really worked out) with the much superior TAP::Parser currently in development.

The wisdom of spending the time on this, rather than just leaving TH as is, was questioned on the TAP-Parser list. The argument was that TAP::Parser would make TH more flexible, but since few people write custom test harnesses now, why bother?

I believe that viewpoint to reveal a commonly held economic fallacy about the nature of demand. It also walks into a handy illustration of that fallacy, which is why I'm posting it here. Here's my reply explaining why our thinking about whether we should spend the time to make something easier should not be ruled by the current low demand for that thing.

-------------------------------

Shlomi Fish wrote: > It is well-known that it is planned that Test::Harness 3.0 will be based on > TAP::Parser and TAP::Harness. It will be a rewrite of Test::Harness that will > aim to be as compatible as possible to T::H. Now here are my thoughts on the > matter. > > As a result breaking compatiblity with it in my fork, was the first thing I > did, after converting the procedures to methods one by one. I originally > planned to write a compatible class to Test::Harness, but eventually gave up > on the idea. From my impression, writing a compatible Test::Harness that will > still benefit from the newer tecnologies will be very hard to do and not > really worth it. > > I think that the number of times Test::Harness, Test::Harness::Straps and > friends were customised (being a TAP::Consumer) is very small and neglibile > compared to the amount of times people just used "make test", "./Build test" > or "prove". I personally heard of less than 10 such cases. And I believe > these cases can easily be re-adapted for the newer technologies.

I live in Portland but I spend a lot of time in Pittsburgh. There's work and $girl here. Portland has a large and healthy bicycling community with many well maintained, interconnected bike lanes following major roads going to interesting places. You can bring your bike on public transit, there's even special bike lockers at the major stations. Maps of good cycling routes in the city are easy to obtain. Many people use bikes to commute to work, even the mayor rides his bicycle. Cars tend to be aware of bikes on the road and they share it reasonably well. Most bridges have bike lanes and sidewalks.

Pittsburgh, on the other hand, has a very small cycling community. Most are what you might call a "fair weather" cyclists. They do it for fun, in good weather, on side streets or on the few dedicated paths. Pittsburgh has few bike lanes. What they do have tend not to connect together well. Its legal to park cars in bike lanes, so you wind up weaving in and out of the bike and traffic lanes. Car drivers in Pittsburgh do not understand how to deal with bicycles and often yell at you to get off the road. The road shoulder which you're riding on tend to be poorly maintained and difficult to ride on. Most bridges do not allow non-motorized vehicles. Almost everyone in Pittsburgh drives. [1]

Riding a bike in Portland is a joy and a lot of people do it. Riding a bike in Pittsburgh is a personal risk and few people do it.

Now if I were to argue for more bike lanes in Portland I could point to all the cyclists and say, "Of course we need more lanes, there's lots of bicycles!" But were I to try to argue bike lanes in Pittsburgh one could point at the *lack* of cyclists and say, "Nobody rides bicycles, why should we spend money on bike lanes when nobody's going to use them? And we already have some bike lanes, but nobody uses them!"

If something isn't being done, is it because nobody wants to do it or because the system makes it really hard to do? Which is the cause and which is the effect? Is nobody writing custom harnesses because they don't want to or because Test::Harness::Straps is incomplete and unwieldy? If you make cycling safer and more enjoyable will more people start cycling?

Let's look at history. Set the Wayback machine to early 2001. Most folks aren't writing tests. Test.pm is all we've got and its badly documented. Do I not write Test::More? Nobody's writing tests, why bother? Fast-forward to late 2001. Testing is starting to gain a little traction and Test::More is pretty good, but people aren't writing custom testing libraries. Do I not write Test::Builder?

In economics terms, lowering the cost can reveal increased demand which would not bite at a higher price. Remember how demand is a curve increasing with decreased price.

Since OSS has a near-infinite supply (high fixed cost for development, near-zero cost per unit) all we really deal with is Total Cost of Ownership for the user. The unknown is what the demand curve looks like. I believe if you look through perl-qa archives you'll find that a lot of people *want* to write (or use) custom harnesses, but the cost is currently too great for them to be arsed to do it. The demand is there, but the price is too high.

[1] Its also really hilly, while Portland is very flat, but why let a little thing like topography get in the way of a good analogy?


Price doesn't affect demand

tomhukins on 2007-06-07T16:19:16

You make a good argument, but decreasing the cost of using something increases the quantity demanded: it doesn't affect demand itself.

In terms of the pictures economists draw, moving the supply curve doesn't move the demand curve, but it does move the point both curves intersect (quantity demanded).

For example, I tried to hook WWW::Selenium into Test::Harness a while ago but gave up as it looked like it would hurt too much. I suspect I could do what I wanted more easily with TAP::Parser.

However, increasing the quantity demanded now increases awareness (list discussion, journal entries, documentation) which may increase demand in the long term.

Price doesn't affect the demand curve

schwern on 2007-06-07T17:09:21

I think we're in agreement, but my wording was a imprecise. "Demand" here can mean two things. The total "demand curve" over all possible prices and the "current demand" which is the quantity demanded at the current price. Its also interesting to note that a free software release doesn't really have a supply curve... not that I can figure anyway.

Price doesn't immediately affect the demand curve. It does effect the current demand. And yes, I agree that increasing the current demand can eventually alter the demand curve over time. The thing people forget is that current demand can be changed by changing the cost and the general inverse relationship between current demand and cost.

Anyhow, IANAEconomist. Salt to taste.

excellent

markjugg on 2007-06-07T16:51:11

Excellent post!

TAP::Parser

AndyArmstrong on 2007-06-07T18:18:16

TAPx::Parser is now TAP::Parser and may be found here:

http://search.cpan.org/dist/TAP-Parser/

Re:TAP::Parser

schwern on 2007-06-11T18:47:25

Changed the references from TAPx::Parser to TAP::Parser.

No?

chromatic on 2007-06-07T18:31:59

Do I not write Test::Builder?

Well, actually....

Re:No?

schwern on 2007-06-07T21:01:35

D'oh!

My brain is revisionist. Props to you for writing Test::Builder.

another classic example

lachoy on 2007-06-07T23:03:35

"Why should I put wheelchair ramps to X, handicapped people never come in here!"

not normal economics

gizmo_mathboy on 2007-06-08T02:50:33

I would add that Open Source is not about Adam Smith economics and group demand. I think it is about scratching an itch and it might happen that others might find it useful.

Some see a need for using TAP::Parser in Test::Harness and bought maintainers seem to be in agreement, if others don't like it there is always the source and a fork.

Re:not normal economics

Alias on 2007-06-08T04:49:18

I would argue that toolchain development is not about scratch and itch either.

It's about brick walls.

Tools are there to make "real" work more productive.

So when it comes to improving or extending tools, the question is one of whether or not it's going to be more expensive in mental effort and human time to extend the current tools, or to just do the job directly.

If tools are easy to extend, people will extend the tools, because that is going to be quicker compared to just doing the job directly. If they start to try to extend tools and hit some brick walls, or tricky coding, then it exceeds the maximum time available to write the tool in and they do the job directly.

This is also the beauty of the ::Tiny modules and other similar things in the "utility" areas. They aren't JUST small in size.

Equally important is that they are one single .pm file that works back to Perl 5.004 and doesn't need a compiler or even really an installer. They are completely malleable and highly approachable, and so they are usable even for small ancillary tasks, not just ones where that job is the main focus.

I've been using Config::Tiny a lot myself, but not YAML::Tiny is mostly working I keep looking at all my config code and thinking "You know, it would be SO EASY to just move those to YAML, and it would make life easier downstream".

Re:not normal economics

sigzero on 2007-06-08T09:56:39

Ha! I have been converting some of our Config::General files to YAML::Tiny this week. Part of the re-tooling effort for the project I am on. : )

I didn't Make This Fallacy

Shlomi Fish on 2007-06-08T07:47:42

I should note that as opposed to what Schwern thought that I said in the post, I did not make this fallacy, nor that was my intention. I told Schwern I was unhappy from him posting this here, and that he has done me a dis-service by that. See my response.

And for the record, my name was the first thing I noticed in this post, possibly due to the horizontal rule and the space and the quote afterwards.