in reply to API complexity measures

To follow on stvn's response, there is a certain amount of complexity inherent to a given system. That complexity has to be dealt with. It cannot be wished or designed away. To illustrate, I once worked for a medical claims company as their web guy. My internal client had this idea that we should reduce the number of mouse clicks. Not a bad plan, except he wanted the user to be able to make three unrelated choices with two mouse clicks. We could have done it, but that would have necessitated tying unrelated ideas together. The complexity was going to come out, no matter what. It's like water in a river. You cannot stop the water - you can only channel it.

Your API change may have simplified your mental model, but would it have simplified the overall model that the author was dealing with? With DBM::Deep, people are constantly asking me for a bunch of optimizations that work extremely well if your process is the only consumer of the DB. Unfortunately, I can't work them in yet because the other use-case is if there are multiple processes accessing the DB. What should I do?


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?

Replies are listed 'Best First'.
Re^2: API complexity measures
by zby (Vicar) on Jun 10, 2008 at 20:21 UTC
    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.
      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'.