The Designer/Developer Division of Labor Revisited (Alternative Title: The Three-Way Manifesto)

The conventional wisdom floating around about template engines is that they facilitate a division of labor between two basic groups: programmers, who are concerned with business logic, and designers, people who are more concerned with the aesthetics of a website.

I reckon that this whole argument has become so commonplace as to have become a kind of overused cliché. Of course, if this is the case, we are as guilty as anybody. Certainly, we dutifully expound this idea in the introductory pages of the FreeMarker documentation. In fact, the organization of our documentation, where there is a separate standalone part that is for designers and another part specifically for programmers, reflects the 2-way division of labor that is being promoted.

Of course, the whole thing has a certain conceptual beauty to it. After all, there are two sexes (approximately, anyway) and most people are at least vaguely aware of the brain mapping research regarding the two hemispheres of the brain and their respective specialties. So, in this vein, that there are two basic kinds of people involved in web development just fits in with all of this in a very conceptually neat kind of way.

Now, I don't mean to say that this is invalid. Of course, different people are good at different things. Having hard-core programmers work on designing web pages is usually disastrous. It is even more obvious that you cannot expect people who are good at graphical design to do much programming. The idea I want to develop here is that the 2-way division of labor is, in the general case, an oversimplification, and it may be better to think of things in terms of 3 basic roles: application programmer, graphical designer, and website integrator.

I guess it is clear enough that application programmers write code in a language like Java. Broadly speaking, they are concerned with defining the back-end data structures and the algorithms that operate on that data. As regards their contact with a templating system, application programmers would, ideally, be able to hand off data to the front end of a system and suppose that it will be displayed appropriately. Graphical designers are mostly concerned with the aesthetics of a website, so they spend a lot of time in programs like Freehand and Illustrator and so on. (As a side note, I, a professional programer, have never opened either of those programs and don't even know what they look like on-screen.)

The problem that I see with dividing the work of web development into the above two categories is that it seems to leave a very big gray area in the middle, where it is not so clear whose territory it is. Now, of course, once things reach a certain level of complexity, one cannot usually fit everything into neat unambiguous categories. So, this is normal, up to a point. But this is really a very very large gray zone. It definitely seems to me that, at this stage of history, to master all of the various web-related standards such as javascript with dynamic HTML, and cascading style sheets, along with technologies such as FreeMarker, is a sufficiently large undertaking that it comprises a respectable professional specialty or subspecialty at least. Insofar as things like Oracle database admin or unix sysadmin are also recognized job categories, there is no reason that this should not be. And I think that, increasingly, it is.

So, I have been wondering whether thinking about web development in terms of a 3-way division of labor will often be more useful than the two-way designer/developer dichotomy. In terms of FreeMarker, it allows us to think more clearly about who uses what features, and the basic real-world problem space that motivates them. (However, I think the 3-way paradigm could also be useful to people who are thinking about developing other, related tools in the space, such as web application frameworks.)

Now, in the 2-way division of labor, how does one go about working up a website with dynamic pages? Well, one way -- the approach I myself have typically used -- is that the programmer types work up some basic web app with very basic, ugly page templates and the templates are handed off to the designers who beautify them. The other way would be for the non-programmers (designers along with the marketing types) to work up the web pages with dummy forms and dummy data and then hand off these pretty but non-functional pages to the developers to templatize them and render them functional.

So, basically, either you start with functional, ugly templates and make them visually appealing, or you start with pretty, non-functional pages and templatize them, rendering them functional. You have these two basic approaches. Which is better? My sense of things is that this would be a sterile debate, akin to discussing whether it is to crack open a boiled egg on the small or the large end. The same result can be achieved effectively either way.

Actually, my sense of things is that if that was all there was to it, the 2-way division of labor would be a reasonable paradigm. The problem with the above scenarios is that they really relate to the initial step of developing a prototype. They don't model the multiple iterations and shifting requirements and (sometime chaos and confusion) that occur over the entire life cycle of the project. It also begs the question of how you reuse presentational elements when you start a new, related project. Surely, you don't want to start from zero each time when so much of the same problems recur over and over... And, in general, there is a danger in thinking that an approach that yields quick results for developing a prototype is going to be the best approach for long-term development; it's not necessarily so.

For starters, in web-based development, a huge amount of painstaking work goes into making sure that a site is usable in different browsers, at different resolutions, and so on. Also, there is a whole set of problems involved with creating branded and localized versions of a product or service. Moreover, I am sure that it is fairly common that new requirements in this regard may be introduced at a fairly late stage of the development cycle.

Now, on the one hand, these are problems that are hardly trivial in nature. But, on the other hand, the same basic problems keep recurring (though with minor variations perhaps). In any case, once you've invested a lot of time into figuring out how to get some nice table-based presentation to show up well on different browsers and at different resolutions, it is natural to want to encapsulate your solution so that it can be reused elsewhere, especially when you anticipate that people will at some point want a Spanish language version of the site, say, or just to do something very similar in another context (though slighty different.) Of course, the basic antipattern of copy-paste-modify is always available, but, just as in hard-core programming, there are huge gains to be had long-term by avoiding this. Once you've solved a problem once, you should want to encapsulate the solution and reuse it. This is true with regards code in java and other programming languages, but there is no reason or the same thing not to apply to HTML.

The problem I see is that, while graphical designers will be good at solving problems related to presenting data, they are not, by training or inclination, well suited towards generalizing their solutions in a reusable way. But I also do not think that the hard-core java programmers are typically very inclined to invest their time in this. Well, if it so happens that we are talking about a common core kind of problem and neither designers nor programmers are typically going to address it, then finally, it seems that there is a need to think in terms of a third kind of category -- a team memer who I shall refer to as a "website integrator", One aspect of this person's work is that they are looking at how to encapsulate presentational elements in a reusable way.

Let's consider this scenario: a corporation of a certain size has a very large web presence. This web presence developed in a chaotic way with different subdivisions investing in disparate web-based projects. Eventually, this entity wants to unify all those efforts and present a common corporate look-and-feel across the board. Ultimately, it seems to me that this would largely amount to having a set of common reusable building blocks; that would bring the twin benefit of avoiding superfluous repeated labor, and also that, reusing these building blocks would naturally tend to yield a certain consistency of look-and-feel across the various subsites that make up that entity's overall web presence.

Probably most readers realize at this point that when I talk about corporations investing in reusable building blocks, I am thinking in terms of FreeMarker macro libraries. Of course I am. However, the comments are still of a general nature, where I am thinking that a templating technology -- FreeMarker or some alternative -- must have powerful enough macro capabilities to support building reusable components.

This leads me to a basic itch I want to scratch. There is a kind of rhetoric about how a template language should be extremely simple. For example, simplicity (i.e. a lack of certain features) is frequently touted as a great feature of Jakarta Velocity. Now, I think that many perceptive people suspect that this is largely an attempt to justify the lack of ongoing development in that project. Certain needed features have never been added, and the simplicity rhetoric can be conveniently trotted out when people bring this up. However, whether the simplicity argument is made in entirely good faith or not, it is fallacious. But here is an interesting point: the fallacy is not readily obvious when you use the 2-way division of labor; in fact, it may largely be a result of taking that paradigm too seriously. The argument is basically that people who work on page templates are graphical designers, so the templates have to be dead simple... However, thinking in terms of the proposed 3-way division of labor, the underlying fallacy is immediately laid bare. Once you think that way, you see that the third category of team member, the website integrator, also works extensively with templates, and a person in that role really must have a template language with macro capabilities sufficiently powerful to build libraries of reusable components. And I think this corresponds to the intuition of people who are experienced in web-based development: in the general case, going beyond little toy projects, yes, you do need these more powerful macro capabilities.

(The other way to deconstruct the fallacy, by the way, is to realize that it is based on extending a solid, sound idea in an unsound way. It is surely bad practice to put application level logic in your page template -- an extreme example would be having your template make direct SQL queries against a database. That is a sound principle, so far so good. However, this gets extended in an unsound way to mean that all programmatic logic, even that which pertains to presentation itself, such as reusing presentational elements should be avoided in page templates. And I think that is fallacious in a fairly obvious kind of way. But again, the 3-way division lays bare the fallacy where the 2-way paradigm does not.)

As a closing note, I am well aware that in very many projects of a certain scale, the programmer and the page designer are frequently one and the same. Thus, many readers could well be thinking: I'm not even managing to have the 2-way division of labor going, and here you are talking about a 3-way division!!!

Well, fair enough, but I don't think it is exactly the point that you must have such a division of labor. I am not saying that. Of course, in real life, even if it is hardly optimal, people will have to wear multiple hats and be jacks of all trades. However, even in such cases, maintaining a clear architectural separation between model and view and the separation of roles it implies is a useful organizational principle. So I would say that, similarly, in the 3-way paradigm, the java programmer, the designer, and the website integrator might all be the same person, or it might be that the programmer and website integrator are the same person, but the graphical designer is somebody different. I would say that, even if you don't manage to have the full division of labor because people have to wear more than one hat, it is still useful conceptually. In fact, currently I am tending towards the idea that the 3-way division of labor is essential for thinking sensibly about what tools like FreeMarker are about, and probably also web application frameworks. It seems to me that the 2-way division has lived past its usefulness and concentrating on it will lead to erroneous thinking.