Anyway, here's an interesting article I just read this morning. I'm really impressed at some of the apparent capabilities of those tools the article discusses. However, the "standard folder structure" described therein evinced a distinctly different approach to the management of client-side code (well, client-side everything, by extension) than what I've come to think of as the One True Way. It's always interesting to read something like that and have one's own notions illuminated by glaring contrast with someone else's. I'm not going to say my ideas are better of course, but I think they're fundamentally different. It's going to be a little hard to describe why, because I don't think I'm equipped with the terminology necessary to discuss the subject; I'm not even sure I know exactly what the subject is. Nevertheless, as I've been preparing to do a quick presentation about the little wallflower jQuery plugin that I wrote a few weeks ago, I've been forced to think not only about the way I actually go about designing and arranging and managing my application as it grows, but also about the way I think I should be doing it.
Back a really long time ago, in the early '90s, one of the trendy must-read business books of the time was Peter Senge's The Fifth Discipline. I guess it says something about how business/management improvement trends go that you can pick up copies of that book now for the cost of shipping. In other words, it's almost literally worthless. But it's a pretty good book, as things like that go. Senge's an interesting guy, an engineer by training who got all fired up about the topic of "organizational learning", and that's what he's been doing at MIT's Sloane School of Management for a couple decades. The book is basically about that: what it means for an organization to learn.
Much of the material in The Fifth Discipline is sourced from the work of two other Sloane School researchers, Chris Argyris and Donald Schön. Since the 1950's, those two have been doing some really interesting work on the theory and mechanics of learning, both individual and organizational. Check out Dr. Argyris's Wikipedia page for a brief taste of what he's written about. One of the lasting concepts I took away from one of his books (which, you'll note, is not considered worthless) is an idea that Senge also latched onto, that of recognizing and contemplating the distinction between theory in use and espoused theory. An espoused theory is something you type into a blog post about how everyone should architect their enterprise application. A theory in use is how a development team actually does it. (Seriously, that book is one of those eye-opening, mind-opening books that you just can't forget, providing enormous insight into all the stupid things that go on in organizations large and small. If everybody read and believed in the stuff Argyris and Schön have written about, the world would be a better place.)
Now I'm not going to pontificate about how you should architect your web applications. My point in bringing up those books and those ideas is that writing about how one does things can be pretty humbling. I know that the way I actually work isn't as close as I'd like it to be to the grandiose fantasies I entertain about The Perfect Application. More than that, however, what I learned from those books is that I should not only be aware of the ways my actual work doesn't live up to my ideals, but also to be aware of the reasons I think those ideals are ideal. What do I want from my application design, and why do I want it? If I were able to fully realize my ambitions for perfect design, would I perform some sort of test to see if I actually was getting what I wanted? That's something that's generally left out of most process improvement activities — and I mean process improvement activities as actually done, not as they're described in books and blog posts. How many teams have you worked on that, after taking up some trendy activity like stand-up meetings, have actually applied an even vaguely scientific testing method to see whether the new activity was helping? How many really analyze the goals for starting their process improvement in the first place, and subsequently test to see if achieving the goals helps out their business bottom line? I think the same rigor should apply to technical processes like application construction and code management, but in my experience that's not so common.
One of the difficulties I'm having with this subject is that I don't know what to call the central activity. That activity is the construction of the application code behind an application, and the design for how that construction should proceed. I use the term "construction" because I've been driving through a bit of it for several months now on my way into and out of town. Civil engineering projects involve an outward architecture: somebody designs what a bridge should end up looking like, the shape of the arch, the look of embankments, the decorations on railings and lane dividers, and all those other things that'll be mostly ignored by the public when the project is complete. However, I suspect (knowing essentially nothing at all about what civil engineers do) that a whole lot of work goes into the design of the construction effort itself. I'm sure that there's a tremendous amalgamation of experience that instructs thousands of planning decisions for a big roadway project. Those must be planned with a rigor that I've never seen even distantly approached in any software project I've experienced. Maybe I've just been unlucky, but I don't really think so.
What do I call, then, the design and planning of software implementation, and by extension the theory of that design? The term "application design" seems to be understood as being more about what an interface looks like and what application users should experience. "Coding practices" to me means "tabs or spaces" and details like that. I'm going to use the term "application implementation design" because I can't think of anything else. I'm absolutely not an expert, of course, as should be clear by this admission that I literally don't know what it is that I'm talking about, or at least what to call it.
I want to minimize the number of dimensions of code expansion that result from a given increment in functionality.In other words, I want it to be the case that when new functionality is called for, a developer should have to type in as little new code as possible. OK well that's pretty obvious; that's what everybody wants. The tough part, however, is being sensitive about what sort of new code we consider to be "matter of course" new code — code that we think of as having to be written due to laws of nature. That's tough because it's easy to grow numb to some things that really aren't laws of nature, but consequences of application implementation choices. For example, in my current application, when I need a new database table or changes to an existing one, I type in a little SQL. To a lot of people nowadays, that seems horrible (or at least that's an impression I've formed). The framework should do that! Well, maybe; I'm aware of how much that part of my world deviates from some current fashion, but in that particular case I actually prefer it that way. In other words, I'm aware of the fact that I've chosen a scheme that requires me to type in some SQL manually, but I know what my reasons are and I'm OK with that.
The implementation of my unobtrusive behaviors
proceeded, generally on an as-needed basis.
A new page would need something, and I'd cobble
together some way for the HTML to announce that
need (a new class name, or grouping under a
particular element id, or whatever) and write
The code evolved along the lines of little
stanzas like this:
var $link = $(this);
Each page feature, in other words, had a chunk
of code that would look for the tell-tale mark
in the HTML indicating the need for some
activity. The "$where" variable was the DOM
root under which I needed the work done, and
was generally either the page body as a whole,
or else a piece of the page into which new content
had just been dropped.
I was lumping all this code into a single routine
that would be applied upon page load, and also
when page fragments were loaded dynamically.
As you can imagine, this function became
ridiculously big after only a short while.
I knew it was awful, but it did work after all
and I had other things to worry about.
So that brings me to this morning. I've been typing in this ridiculously long ramble for a while, but not until I saw a couple of posts about "enterprise" components did a unifying theme really click in my head. I'm delighted that people are finding success with smart dependency management schemes, and I'm sure I've got a lot to learn about large-scale web applications from other people approaching the problem in more well-informed ways than I did. (That'd probably be just about anybody doing it.) However, there's a lot I like about the world I've made for myself. What are the "laws of nature" that I'm assuming? Where are all my unnoticed wastes of time? Would one giant script file really work out in an application of the scale that my previous position involved? I'm not really sure at the moment. I also don't know whether what I'm doing is something that lots of people do, that's been written about elsewhere, possibly extensively, and possibly with well-reasoned heavy criticism. If you know, and you're not too exhausted after reading all this stuff, leave me a comment or two.