But to the real question. In this specific case I definitely disagree. A set of glorified marked up HTML pages that parallel a set of CGI scripts does not necessarily a maintainable design make. Suppose, for instance, that you are putting together website where several of the pages have a large chunk (say about a third) of the page in common. What approaches would you take? Well here are some options:

1. Maintain the HTML for those pages as HTML.
2. Maintain the HTML for that chunk as a separate component and drop it into all of your pages.
3. Incorporate the HTML into your code and factor as you normally would, factoring that chunk out in common.

1. Maintain the HTML for those pages as HTML. Well HTML has no real include mechanism so that common chunk needs to be maintained in parallel between those pages. If that chunk includes dynamic content, this could be an ongoing issue. But you do preserve the ability to use standard HTML WYSIWYG tools to modify the page.
2. Maintain the HTML for that chunk as a separate component and drop it into all of your pages. Tools like the Template::Toolkit make this easy and natural to do. You now lose the maintainance problem of maintaining pages in parallel. However you have also lost the ability for designers to conveniently use WYSIWYG tools on your pages as a whole (they can on each component, but more knowledge is needed to work this way), and now people maintaining the HTML or code needs to understand the layout of your templating system to work on your site.
3. Incorporate the HTML into your code and factor as you normally would, factoring that chunk out in common. Again you lose the maintainance problem of maintaining pages in parallel. On the flip side you now have code and HTML mixed together. But you don't have the conceptual overhead of a template system to work with and the mix of skills required is fairly readily available.

This is a classic maintainance problem, just restated in terms of the web. Maintaining parallel content either requires ongoing extra work, or it requires that you find a way of factoring your problem. With the web your issue is that the design tools that designers like to use tend to not play well with trying to factor the problem. The three answers I gave trade off differently depending on what resource you can most easily waste: HTML designer's time (on synchronization), programming time (on figuring out how to modify code to produce different HTML), or a bit of everyone's time (on setting up and maintaining a clean separation).

Well, to beat a dead horse a little... my statement was catagorical, and "smoke alarms are always good to have in your home" is also catagorical. :) (though really, "home" is a qualifier, as was the exception for programming communities I gave, so maybe neither are really catagorical enough to make them probably untrue on that basis.)

I am not sure about your "parallel" idea. With the straight HTML sollution it could be, but also you could just use an SSI for the common chunk, making some sort of intersection.

I think restating the classic problem in the terms of HTML doesn't work, because HTML isn't a programming language, and non-programmers like/need to change the way it looks. That's the point I was trying to make. It is not a point I would be making in a typical programming case; in a typical case, I think that it is okay to expect people to put the time in to understand the tools they are going to use, and that expectation totally changes the values of the tradeoffs. Then I would be looking for the simplest sollution. In web design, though, I am looking for the simplest sollution for two groups of people, and I think the choice ends up being between mediocrity for all (HTML with SSI, or CGI.pm) or seperate quality sollutions for both groups (simple templates).

Does Dream Weaver handle doing things with SSI?

Using SSI is again a step away from having the displayed HTML documents being structured like what your web authoring tools work with directly. Different technology, but same idea and same tradeoffs.

As for whether the classic programming problem is appropriate to HTML, I absolutely disagree with you. Of course it applies. The problem has zero to do with being a programmer, and all that programming brings to it is another problem domain that hits it, and more ways to tackle it.

A general statement of the problem is that whenever information in two places has to be kept in sync, humans tend to make mistakes. Examples of where it arises:

1. Any interface within a program hits it.
2. Changes to code and comments.
3. Having documentation track a working system. (Program, business organization, etc.)
4. Keeping marketing documents presenting the same (current) message.
5. Keeping telephone lists in sync with people's telephone numbers.
6. Keeping references to figures and chapters in a book in sync with where the referred to information is.
7. Keeping URLs in HTML in sync with where the referred to object is.
8. Keeping classifications of books in sync with the current classification system. (Classifications are not totally static.)
and so on.

In other words this is a fundamental issue with content-management. It has nothing to do with programming, and the underlying problem hits people both in and out of programming. Consider carefully what a form letter is. Does it take a programmer to write one? Apparently not. Bosses had form letters drafted up well before people introduced computers into their offices. Some of the most sophisticated uses of document templates that I know of are from lawyers. Publishers have known to push off the actual work of getting the numbering right on footnotes to the typesetter for centuries. Telephone companies have known for decades that it is cheapest to routinely create new telephone books from scratch with almost the same information and give them to everyone (instead of just explaining what changed).

It is all the same problem. Failure to recognize that is IMHO failure to understand what the nature of the problem really is. The only thing that changes is what the tradeoffs are between ways to try to attack it. Programmers in particular encounter it very often in many different ways, and so have an unusually rich set of approaches. But you can tell any editor that keeping information in documents synchronized is a pain, and they will agree.

Now in this case you want the best solution for everyone. Well the best solution for a programmer is going to be to manage complexity by letting them apply their programming skills. The best solution for a web designer will be to pass problems off to the WYSIWYG tool of the day, allowing them to forget about mechanics and concentrate on the overall result. There is no solution that is truly best for the two of them, they want to work with the same things in such different ways.

So you have to accept tradeoffs and compromises. And repeat it as often as you want, my direct experience says that the tradeoff does not always come off with separating code and HTML being a win.

PS: In reference to your comment about project managers, here is my solution. My project manager is a better programmer than I am. I can't tell you how to get into that situation - for me it was luck - but I can tell you that it makes life easier than when I had to deal with people who didn't know what they were doing but thought they did. (I still think that the most pleasant management experience was someone who didn't know how to program and knew that. But he had an uncanny instinct for identifying everything a dumb user would wonder at...)