July 6, 2006
Web Development: Engineering Geeks vs Design Geeks; Small Teams vs Large
I usually resist the urge to blog something that appears on Slashdot, on the theory that it’s old news within fifteen minutes, and most any response can be found in the comments (which can be pretty good if you have the right filters). But IBM Developerworks recently published an article on Ruby and Seaside by Bruce Tate. Read it, then come back.
Maybe I’m dumb, but let’s summarize what you’ve just read:
- Ruby supports string interpolation, which has only been a hallmark of scripting languages for 20 years (and
eval()for, what, 15 years?)
- Ruby can be embedded in Apache, “raising the bar” for CGI programming, like, um,
mod_python, and, um,
- Embedding code inside HTML is a good thing
- Objects (that is, code artifacts) rendering themselves is even better
I’m sympathetic to the “Java is soooooo 90’s” crowd, which first latched onto Python, and now are big into Ruby. I like Python, and I really like many of the design choices by the Rails framework developers. (Chowhound, another recent CNET acquisition, recently relaunched using Ruby on Rails. I doubt they could’ve had such a quick turnaround in Java, and I’m really hoping to learn from their engineers when they re-emerge from the depths.)
Purely anecdotally, judging by some of the recurring healthy debates on my team, Java web development is lacking, and the plethora of competing frameworks tends to make things worse, not better (rule of thumb: the number of religiously held viewpoints grows exponentially with the number of competing frameworks; corollary: the number of affordable candidates who are genuinely experienced in your framework of choice and not just futzing with their resume’ decreases exponentially with the number of competing frameworks).
Bruce and many people in the Ruby (and, especially, Smalltalk) community are smart, hard-core engineering geeks. It’s no surprise that niche frameworks cater to smart, hard-core engineering geeks. But as soon as you separate the engineering geeks from the design/webdev geeks, you have a problem. (And, really, as soon as your team grows large enough, and enough work is being done simultaneously, you have a problem. Not to mention the overhead of context switching.)
I can be incredibly dumb/dense sometimes, so let’s discount me: design geeks are not dumb, they’re just familiar with different things than engineering geeks. The more you intermingle code and presentation, the more your team will spin its wheels. I’ve seen it happen. I’ve heard horror stories that make my team’s worst moments seem tame. Why on earth would you want to go back to a time before MVC was commonly implemented?
Through the years, I’ve developed a theory of medium-sized teams. Wanna hear it? I call it the co-dependency theory of web development. It runs like this: engineers (me included) like to be in control, so they build systems that they can easily modify on their own, however convoluted or difficult it may be for non-engineers or new hires. This causes other teams to always run to engineering when a change needs to be made. But that’s good, because engineers (me included) like to feel wanted: so we gladly modify the system on our own everytime a change needs to be made. And web developers/designers? They like it, too. Less work to do, less hassle (and engineers, after all, are not known for their, uh, our documentation skills). Who’s enabling whom in this scenario, I haven’t determined. When I do, you’ll have to buy my book to find out.
All kidding aside, let me summarize what you’ve just read, after you read what you had already read:
- web development frameworks are for more than engineering geeks; they should show the same separation of concerns that engineering geeks like in their own code: overhauling the presentation using the same features and data should not require any engineering work
- design geeks are smart. well, usually smarter than me, anyway
- I’m a co-dependent egomaniac…uh, that is to say, never trust an engineer who says “trust me, I’ll do it for you by morning”; read your Bible, especially the part about fishing
Your task, should you choose to accept it: publish a blog post purely by having Word objects render themselves to a page, using an XML configuration file to determine the order of words to publish. It’ll be easier than working with a large-ish team on a large-ish web site for more than two years if the code and presentation are intermingled.
Update ~10:35p: In case it’s not clear, Tate’s article, as published, comes across to me as representing a big step backward from modern web frameworks (Java or not). I am not dismissing the Ruby on Rails community, nor the Java community–least of all, my own team. I probably should have focused more on why advocacy articles like that one almost always fail to satisfy, but there is a real point that niche, engineering-geek-culture-driven frameworks tend to focus on rapid prototyping and small development shops, and practically assume engineering geeks should (or could!) do it all. (Note to self: don’t blog as a means of using up your nervous energies when you’re tired and want to go to bed.)