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.

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.