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.

I agree with you (and Abigail-II) that attempting to build flexibility when you don't need it is not a good idea. Never would have thought of disagreeing with that.

I am just saying that flexibility and complexity have a more complex relationship than just being traded off. If you attempt to achieve flexibility by embedding decisions everywhere in switches, well I guarantee it will always cost you. But I have seen many cases where you can both get simplify code and make it more flexible at the same time. Furthermore I think it important to point this out because in these cases the programmers often have trouble seeing the possibility because the choices you make seem counter-intuitive.

For a concrete example, take a look at Re: Re (tilly) 6: To sub or not to sub, that is the question? and compare the original and my rewritten version of get(). The rewrite is both shorter and more flexible. Furthermore with no visible code it manages to add a number of features that the author wanted.

This is an attempt to formalize the argument of Abigail-II - it obviously has a flaw, but can be an starting poing for further analysis. First we need a to define the complexity of a design - I would take for it the Kolmogorov complexity (in Perl) i.e. the character count of the shortest Perl program complying with it. For the definition of design I would take an additionall set of rules that the program has to comply with.

Now that is sure that a problem without any additionall requirements on the solution program is of less complexity than one with some additionall requirements. This of course holds when the requirement is the plugin architecture.

The problem is if the Kolmogorov complexity is really the complexity perceived by humans.