in reply to Re: API complexity measures
in thread API complexity measures

Sure there is inherent complexity that cannot be sensibly reduced. But there are also cases where there is too much complexity in an interface. My question was about that second case.

Replies are listed 'Best First'.
Re^3: API complexity measures
by dragonchild (Archbishop) on Jun 11, 2008 at 12:14 UTC
    You asked about a measure. That measure is how you would determine between the first and the second cases. Otherwise, you have your gut to go on. Guts are very poor measures of anything.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      I am not sure if I understand your point - but if what you say is that you can never tell if the complexity measured by some measure is below the practical lower bound of complexity - and so any measure is impractical? Then I don't agree - you can argument if a module does all we want it to do (and thus that it is above the minimal practical complexity) separately from measuring it's complexity. And the difficulties with the first don't make the second just 'gut feeling'.
        You asked about a measure, the question initiated because you felt that a given API was overly complex. Both stvn and I replied back indicating both that
        • complexity is a very hard thing to measure with the tools we have
        • most people who think they understand the complexity of an API usually don't
        This isn't a slam on you. Both stvn and I gave you examples from our own CPAN module where people asked us to reduce complexity in an API when they didn't understand the full measure of the requirements. A lot of that is our fault - OSS developers tend to hack first and document at some undefined "later". This leads to users (quite understandably) assuming that their usage of the module is the primary one because there is no indication otherwise. stvn has dealt with this almost weekly with Moose and Class::MOP. mst deals with this constantly with Catalyst and DBIx::Class, often from me.

        This reminds of the three-body problem. Analyzability starts to break down very quickly.


        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?