On Repeating Oneself

This is in response to ppk’s blog post DRY: Do Repeat Yourself. If you’re not interested in Web Development or Computer Science, or just don’t want to read that post, you may stop reading now and reward yourself with a near-infinite number of kittens.

A significant middle part of my career was a sort of Web Development coming from a Computer Science background. Working on the BlackBerry 10 Browser (the first mobile browser that was, itself, written as a web page) we struggled to apply, from day 0, proper engineering practices to what ultimately was web development.

And we succeeded. Mostly. Well, it was alright.

So maybe PPK is wrong! Maybe webdev can be CS already and it’s all a tempest in a teapot!

Well, no. The BB10 Browser had one benefit over other web development… one so great and so insidious I didn’t even notice it at the time (iow, privilege): We only had to build the page to work on one browser.

Sure, the UI mostly worked if you loaded it in Chrome or Firefox. That’s how we ran our tests, after all. But at the end of the day, it only needed to work on the BB10 version of WebKit. It only needed to be performant on the BB10 version of WebKit running on just a handful of chipsets. It only needed to look pretty on the BB10 version of WebKit on a handful of phones in at most two orientations each.

We could actually exhaustively test all of our supported configurations. In a day.

And this is where true webdevs would scoff. Because uncertainty is the name of the game on the Web. And I think that’s the core of why CS practices can’t necessarily apply to Web Development.

When I was coding the BB10 Browser, as when I do other more-CS-y stuff, I could know how things would behave. I knew what would and would not work. (and I could cheat by fixing the underlying browser if I found a bug, instead of working around it). I knew what parts of the design were slow and were to be avoided, and what cheap shortcuts to employ in what situations (when to use layers, when to use opacity, when to specifically avoid asking the compositor to handle it because the shaders were quick enough (thanks to mlattanzio, kpiascik, tabbott, and cwywiorski!)). I even knew what order things were going to happen, even when the phone was under load!

In short: I knew. Because I knew, I could operate with certainty. Because of that certainty, we wrote a browser in about a year.

But I know webdev is nothing like that. I’ve been on cross-browser projects since and tried to find that sense of certainty. I’ve tried to write features for screens of bizarre dimensions and groped for that knowledge that what I’d done would work wherever it needed. I’ve struggled to find a single performant and attractive solution that would work on all renderers and have felt the sting of my CS education yelling that I shouldn’t repeat myself.

I still scoff at the bailing-wire-and-ducttape websites that litter the web and bloat it with three outdated versions of each of a half-dozen popular frameworks. But, like the weather, I know the laws that motivate it to be so. Complaining is just my way of coping.

The question becomes, then, is there anything CS that can be applied to webdev? Certainly test-driven development and other meta-dev techniques work. The principles of UI design and avoiding premature optimization are universal.

But maybe we should be thinking of it the other way around. Maybe CS should accept some parts of webdev. Maybe CS educators should spend more time on uncertainty. Then CS students will start thinking about how much uncertainty they are willing to accept in their projects in the same way we already think of how performant or cross-platform or maintainable or verifiable the result needs to be.

I hope a few CS graduate students pick up PPK’s call for “Web Development from a Computer Science Perspective” theses. There’s a lot of good material here that can help shape our industries’ shared future.

Or not. I can’t be certain.