We are in the midst of the greatest mass extinction since the demise of the dinosaurs, and
The Kill-Off describes whom (yes whom) is to blame, and why this culling differs qualitatively from those that have preceded it...

There's been a thread in comp.object about refactoring to MVC. The intent is to tame a purported Swing UI monstrosity, and instead to move towards MVC by-the-Hoyle.

Hmm. I'd have scored Swing as being well within the broad outlines of MVCs intent penumbra, if not umbra, already.

The broader, more interesting question is why the Swing solution is regarded as a Frankenstein. Those components mesh better than most I've seen. Swing is a modern, third-generation (nth?) design / architecture. If programmers regard it as hopelessly Byzantine, what hope is there left? What's the problem with Swing? Is it so broad that its hard to learn? This could be so. My experience with it has been the learning curve is something well short of gentle. Issues like layout intrude far to early for my taste. Few components work out of the box. Is it capriciously arbitrary? Is it that the elements integrate in something short of a "seamless" fashion? They do seem to demand arbitrary trowel work, and more mortar, than one would expect of a framework that aspires to being the substrate for pre-fab solutions.

Is the problem that Swing had to be rolled out essentially finished? It had to emerge full-grown. Many species bear young that have to fend for themselves. Few that engage in the quality side of the quality vs. quantity trade-off abandon them. Yet, being bound to your mistakes as soon as you publish an API really really does constrain evolution. It's team players vs. defectors, as always, once again.
How do we avoid the lumbering pageant of slow, coarse grained growth / expansion / dominance and extinction?

The picture to the right is of Tryve Reenskaug, who built the first implementation of MVC at Xerox PARC during the early '80s. (The picture was taken by yours truly at JAOO 2003, in Aarhus, Denmark last September.)
Danny Dig, of UIUC's DCS, gave a nice presentation on the history of this pattern complex / compound pattern / architecture on the same day that Ralph Johnson braved the Big Ball of Mud quagmire. He accurately chronciled the trend towards closer coupling between Views and Controllers, and the ascendance of Mediator objects that buffer the relationships between Views and Domain objects.

The more intimate relationships between Views and Controllers has been driven in part by the absorption of input event generation facilities into the operating system, and its attendant low-level I/O facilities. The more refined divisions of labor among Views, Domain Objects, and the intervening Model / Adapter / Mediator / Mediaptors has been driven in part by the desire for GUI independence, and in part by the rise of automatic GUI code generation tools. Given this, designers are forced to foist their components on the world, ready or not. They must be treated as mature, full-grown artifacts before they are refined in the crucible of full-scale deployment.

I'm as distrustful of and unreceptive to fancy continental scientific ideas, such as Pasteur's germ theory, as the next American. Thus, you can imagine my chagrin when, after being surrounded by people with a nasty respiratory ailment for most of the last week, I woke up with a seemingly identical ailment today myself.

I must reluctanlty concede that this Frenchman may have been on to something with these pathogenic contagion notions of his. I suppose, all and all, that this is a less unsettling explanation that divine retribution. In any case, I find myself with no voice. Except this one.

This epigram is an old favorite of ours, and evidently quite a few others. I tried tracking it down, and came up with a gaggle of purported attributions, going back as far as Mark Twain. I'd like to believe the Twain attribution, but I've yet to find a solid citation for its source. The quip appears without attribution in a number of places, leading me to wonder if anyone really knows where it came from...

I had the distinct priviledge this afternoon of hearing Ralph Johnson (yes thatRalph Johnson) present our hoary chestnut, Big Ball of Mud to his Software Engineering seminar. The mere prospect of this caused me to start reflecting on it...

I still find myself haunted by Kent Beck's critique that this masterpiece of equivocation ought instead to have had the "courage of its convictions".

I've become increasingly receptive to this perspective over the years. Is there something about the metaphors we use to descibe software that blinds us to its fundamental nature? Is that untidy tangle we dismiss as anomalous really part and parcel of building this stuff?

The set of systems that can feasibly be built at all is strickly larger than those that can be built elegantly. For many tasks, and for many teams, this architectural style may be the only possible match.

We made a point of saying, and so it is oft said, that this paper should not be seen as an endorsement of Big Balls of Mud. Indeed, we made it clear that we were, by no means, recommending these kinds of designs. At the same time, we resisted considerable pressure to utterly repudiate this architecture, for a variety reasons.

For one thing, tangled legacy systems leave programmers no choice but to cope as well as they can. Infantry-style teams and processes insure system made in the team's image. Some problem domains may pose requirements so inherently muddled that must inevitably be mirrored in any possible solution.

While I still can't say I recommend this approach, I'm convinced that it was high time that someone try to describe and explain it. This architecture may as well be placed honestly and openly on-the-table, since its spectre looms large over its more respectable alternatives.

Noble et al. have nominated this work as perhaps one of Computer Science's first post-modern works. I'm quite sanguine about this characterization. I realized during Ralph's lecture that a legitimate descontruction of our argument, that is to say, a characterization of our unstated posture, might be that small teams of skilled chraftsmen can beat an underskilled human wave approach every time. Were we really advocating a world made in our (presumed) image?

And, this Slashdot nugget on role fragmentation suggests yet another possible perspective on this multi-faceted issue. (And, yes, it feels rather pointless to echo a Slashdot post in one's own weblog, but what the hell...)

Ralph observed at one point that Big Balls of Mud are what you get when you throw an army of Visual Basic programmers at a problem, and further, that that's just what you ought to expect to get. It's yet another corrolary to Conway's Law. Given that you've elected to employ a large number of modestly talented "infantry level" coders, a haphazzard hodge-podge is what you should properly expect.

Now, back to Beck's challenge. Kent made this remark, I've recently realized, back when his ideas about Extreme Programming were taking shape. XP would ultimately relegate concerns about design aesthetics to a secondary, or even tertiary position in its pantheon. You Are Not Going to Need It demanded that design flourishes be eschewed in lieu of immediate, established requirements. It is a defiantly utilitarian process that ultimately came to scoff at the petty egotistical inclinations of designers towards generality, extensibility, and elegance. Indeed, it gently mocks these inclinations as soft of wasteful hubris. Looking back, it seems that Kent had begun to see the Sirens of Elegance, of High Road Architecture, as of the major obstacles on the road to a more dependable software development process.