Bridging the Gap

I’m a sysadmin. I build the machines and install the networks,
OS’s and software to run websites, email, intra-office networks
and all the different things that we’ve come to expect from the
web. I read all the geeky news sites, play with all the great
software, and run my own website from my residence. For a long
time, I thought design was an afterthought. As long as the
platform and codebase were solid, making the
site/application/service look pretty should simply fall into
place.

The more I experimented with design, the more I realized this is
not so. The site that I adminster during my “regular day job” is
entirely dynamic. We can uniquely display thousands of products
from a handful of files on the servers. While I was debugging
some performance issues, I came to realize that I don’t live in a
vacuum.

It’s easy for admins to feel ensconced in the top of our ivory
towers, with ssh’d root shells all over our desktops, issuing
cryptic commands to servers located all over the planet,
decreeing how things will be to the developers, designers and
users we work with. I bring a set of vital and unique skills to
the team, certainly, but all the kernel hacks in the world are
useless unless the application is designed to work with its
platform.

Decisions were made during the architectural phase of the
software design that I wish I’d been able to provide input to.
The developers did a fantastic job of writing code that creates
customized pages based on the user’s preferences and browsing
history, no doubt about that. However, they did so at the expense
of extremely costly overhead in terms of opening IPC sockets,
reloading classes into memory with each new session, a flat
database where each process had to generate its own queries, and
so on. In short, they coded for coders.

The UI designers were stuck with a codebase that forced them into
designing a user experience based on where the coders thought
they should go, not on their own browsing habits. This was all
installed on an out-of-the-box Linux distribution with no regard
for the unique stresses of serving dynamic content.

This is not a postmortem, nor is it an attempt to cover my ass
and lay the blame somewhere else. It’s an illustration of why we
all need to rethink our relationship to the other people in IT.

Way back in the days of W3C 3.2, the “UI” people could hand an
admin a tarball full of files; the admin simply had to put the
files in the proper place on the server, and ta-da! Instant site.
The admins could focus entirely on squeezing a few more
transactions per second out of the server and the OS’s TCP/IP
stack, and the designers could focus on cross-compatibility and
aesthetic issues. That’s not true anymore.

Unfortunately, most webworkers I meet still believe that nothing
has fundamentally changed.  Developers are still writing code
that works just fine on the development environment, without
thinking of what happens when 200 simultaneous requests for the
resource come down the pipe. Admins are still building servers
that “are comfortable to work in”, rather than streamlined to
transfrom a URI into a chunk of HTML to send back to the client.

Let me take this opportunity to say that not everyone is working in a vacuum. Hundreds of coders are going over the source for servers everyday, looking for more efficient ways to process transactions. FastCGI, Tomcat and XSSI [I mention these because I’m most familiar with them] can create unique content at rates undreamt of just a couple years ago. Designers are acutely aware of the effect of file size, and I would say that most have at least a decent understanding of how expensive various serverside technologies are. There is some absolutely fantastic work being done on the web today, and we can all learn from the operations that have managed to integrate development, design and implementation for the benefit of J. Random User.

The fact is, every decision in the process of building a site needs to have one, single overriding priority from which everything else follows: What is best for the user?

As much as we all crack jokes at the “users” expense, the fact is they pay our salaries. Should a user have to jump through hoops because someone thought it would be easier to write a series of IF/THEN statements rather than a single CASE statement? Is it necessary to open a socket between the server and the backend everytime a page is reqested, or can we use SSI’s, shell scripts and a cron job to update the content periodically? Should we send scripts down the wire to the client that behave differently based on which browser they encounter when they get there, or is it more efficient to configure the server to respond differently to different browsers?

The line between “server” and “application” is blurring more and more every day, and by the time XML is the universal format, it will be indistinguishable. To make this invisible to the person dialing up on a 56k modem with a P-100/32M RAM with “a few hundred colors,” we will have to work together. All of us.

I’m not sure how to make this happen industry wide. I’m not a “business visionary” or a “dotguru.” I’m just a guy with a good engineering sense who takes pride in implementing wonderful technologies for the world to use.

I’ve made a point of working as closely as I can with my developers and designers, and I’m a much better sysadmin for the effort. I’ve learned things about coding that would have taken me months to realize, and I’ve learned more than I ever thought there was to know about UI design (not that I’ve, ahem, gotten around to implementing any of this on my personal site yet).

In turn, I’ve been able to expose the developers to different serverside technologies, and illustrate how they fit together. I’ve been able to show the designers how servers work, so they can reduce the amount of time they spend “trying to put stuff where they think it should be” and focus on making pretty and functional UIs.

Frankly, that’s the most rewarding thing that’s happened to me professionally since the first time I installed a server, opened up my browser and got the “Congratulations! Apache has been successfully installed” page.

After all is said and done, after the developers have written tight, extensible, well-documented code, after the designers have squeezed their brains dry creating a friendly, easy to use interface, and after the admins have built networks that move packets without a collision and installed servers so streamlined they idle at 0.01% resource utilization, it’s still all about building the web and developing something worthwhile to J. Random User. We can’t do this alone any more.

Notes#section2

I separate developers, designers and admins in this article. We all know that there is quite a lot of overlap in the real world. The definitions I use are: developer: creates serverside code that translates objects into HTML designer: creates HTML, images, and clientside scripting administrator: responsible for the installation and operation of the physical networks and server platforms