Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

schwern (1528)

schwern
  (email not shown publicly)
http://schwern.net/
AOL IM: MichaelSchwern (Add Buddy, Send Message)
Jabber: schwern@gmail.com

Schwern can destroy CPAN at his whim.

Journal of schwern (1528)

Thursday June 07, 2007
09:22 AM

The fallacy of assuming constant demand

[ #33460 ]

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?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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, incr
    • 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
  • Excellent post!
  • TAPx::Parser is now TAP::Parser and may be found here: http://search.cpan.org/dist/TAP-Parser/ [cpan.org]
  • Do I not write Test::Builder?

    Well, actually....

  • "Why should I put wheelchair ramps to X, handicapped people never come in here!"
  • 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.
    • 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 sta
      • 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 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 [hexten.net].

    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.