All the Perl that's Practical to Extract and Report

How do you want your complexity?

jonasbn on 2007-12-07T21:46:22

To sort of follow up on my journal entry on released based development.

We distribute our applications as large bundles of modules, collected under a common name space per application. This mean that they can easily be distributed as CPAN distributions, since the structure is somewhat similar and all we need to introduce is a build system (which I have done).

But we have another problem and that is that some of these applications start out using some particular back-end, which may at some point become interesting to another application. So when this usually happens I rip out the module, rename it and build a separate distribution, so the using module can now specify a dependency towards the new distribution and the two using modules can be installed on separate application servers, together with their dependencies.

Not everybody involved have done so or use my build system, so sometimes I am caught in a situation where I have to install a huge application in order to utilize something small like a single module.

I am all for that we should not introduce complexity like distributions and dependency hell until it is required, but what have proven to be necessary is perhaps some guidelines on when to separate out, seen it seems like it is always me who takes the step of doing so.

Another thing is our technical lead who want the name spaces to follow the Online presence. Which makes perfect sense, but it holds some cons like:

  • Huge bundles
  • Installation on several application servers are difficult
  • Installations might be misleading and does not necessarily reflect actual invocation configuration
  • Dependency on bundled components from other apps, require installation of large bundles, which brings us back to the top
  • Release based development is difficult, since somebody else might be hacking on another corner of the app, without your knowledge, which has happened a few times, where deployment broke existing functionality


I can see that we do not want to have a gazillion distributions (or do we), but I tend to think that smaller lego bricks give the best results, the higher the granularity of control the better control.

I used to play a lot with legos when I was a kid, now I have kids of my ownm but we are still only playing with duplos - duplos are great, you can get a lot done in no time, but the results are often bulky and does not have the nifty features you can introduce in your models when doing the regular lego bricks and they do require a bit more imagination to translate to the real world they are replicating.

Yes, software development is complex and we constantly aim to manage and minimize complexity, but should we introduce the complexity in understanding a large bundle of stuff or should we have the complexity in the dependency tree. I prefer the latter since we have tools to address this.

So how do you want your complexity?

Complexity? Bring it on!

mr_bean on 2007-12-08T01:22:51

But please let me be the winner at the end of the day.

Re:Complexity? Bring it on!

jonasbn on 2007-12-09T10:43:14

Well you will win in the end, but it boils down to what a kind of victor are you? and what strategy do you use :)

Re:Complexity? Bring it on!

mr_bean on 2007-12-10T07:54:45

I think the answer depends on whose carpet the
complexity is being swept under.

If the others are less good at handling it,
or the results of their failure are more
catastrophic, then the less they have to handle
the better.

I don't think there is any technical answer.
that can be given in terms of the build
system, other than that the standard,
traditional way, whatever that is, is less
complex.