in reply to Re: Multilevel flexibillity
in thread Multilevel flexibillity

I don't find this an obvious trade-off.

In fact it seems that very flexible code is often also very simple. This is particularly common when flexibility has been achieved by a modular plug-in architecture, and new features have been added through plug-ins rather than through complicating the core design. (There are, of course, significant overheads in resource usage with this approach.)

Replies are listed 'Best First'.
Re: Multilevel flexibillity
by Abigail-II (Bishop) on Jun 25, 2003 at 13:05 UTC
    Well, I think that proves my point. Surely code that doesn't have a plug-in architecture is less complex than code that doesn't have the additional code to deal with plug-ins. But it's also less flexible.

    Abigail

      A core with hooks for plug-ins, and then a few plug-ins that come standard often is less complex than monolithic code which provides natively the flexibility in those plug-ins. This goes double if the monolithic code attempts to add functionality to compensate partway for what in the other architecture can be safely left to optional plug-ins available elsewhere if you care.

        Agree completely.

        However, I don't think that's the position being put forward by Abigail-II (it's not how I'm reading it anyway).

        The "problem" with flexible architectures is that they are sometimes misapplied to simple problems. Having an infrastructure more complex than the domain requires adds overhead and complexity that causes more problems than it solves.

        A three-tier XML/XSL based system is fine and dandy if you need to run a multi-platform, multi-lingual e-commerce system with workflow management and a CMS. You need the infrastructure to separate concerns and make the system comprehensible and maintainable.

        If you just need to print "hello world" it's overkill - and carrying around the unnecessary infrastructure overhead makes the code harder to understand and maintain than a simpler system.

        Over the last couple of years I've been getting more and more enthusiastic about agile development methodologies like extreme programming - where you only add the infrastructure in at the point when you need it.

        As weirdly counterintuitive as this initially seemed, it works amazingly well in my experience. If you keep your code tight and well factored adding the complexity when you need it isn't hard. By avoiding the complexity until you need it you get to work with a smaller and simpler codebase that allows you to develop faster.

      The overall complexity might be bigger. But I would argue that the overall complexity is not the most important factor in understading the system. The important factor is something that I would call the 'complexity of the viewing window' - that is how much complexity there is in each whole 'view' of the system. This is quite vague thought - but I'll try to explain it.

      With good plugin architecture you can partage the whole code into isolated parts with low complexity, you can view each part with a low 'complexity of the viewing window'. What is more you can view the whole system with a low 'complexity of the viewing window' too - since you don't need to know all the details of how those plugins are coded - you just need to know how they are assembled.