Agile Web Operations

Photo by Mike Baird

The bigger a ship, the longer it takes to turn around. This old adage certainly applies to today's businesses, and if you're fighting to spin the steering wheel of a large vessel (by trying to change the work habits of hundreds of employees), you're in for a long battle. But don't let yourself get discouraged, because this is one instance where persistence literally pays off.

Start small but think big

You've worked for weeks on presenting a radical restructuring of your company's organization. Besides re-organizing team structures, you're also introducing ITIL policies to your operations department. You're convinced that these changes will allow the company to massively scale its customer base while increasing its operational prowess. Finally, the big day comes and your "Help me change the world" speech is applauded as divine inspiration. Yet weeks and then months slip by with no progress on any of your suggested initiatives. It seems your presentation was silently ignored and you're wondering how to get through to these people.

Photo by woodleywonderworks

Let's face it, compared to other engineering disciplines software development is just coming out of the stone age. Heck, I'm sure I'll get a lot of flak for even suggesting that software development is an engineering discipline (though I have to admit the way a lot of developers go about their work, calling it engineering does seem a bit of a stretch). Real life is seldom black and white, but I'd like to describe the two basic camps below.

Serial processing through departments for Release X.Y.Z

Most of us have worked at a place like this and, unfortunately, most of us still do. You know what I'm talking about - a traditional shop running with the waterfall process. Each department spends months working on a feature that ultimately, not many people are thrilled about releasing.

 development is finished when the calendar has advanced to a mystical date picked out of thin air months before

 after "finishing", the QA department can begin testing and will find the bugs (after all, this is their job, right?)

 operations is generally the last to know about the new feature resulting in emergency architecture meetings, more compromises, and even more delays

Developers are people too. Believe it or not, they have needs and wants just like everyone else. Here are some, which the Operations department should be able to satisfy for a more harmonious and productive workplace.

Robust development environment

Just as sysadmins have those black sheep servers in the back of the server room used for testing the latest and greatest version of sysinstall, developers need a dedicated sandbox where they can try out all their great ideas. Give them some elbow room in their development environment (at least 4 GB of RAM), plenty of disk space (500 GB) and a quad-core workstation. What in the world would they need this much power for on their desktop? Virtual machines, heap dump trace analysis, and virtual machines. Did I mention virtual machines? These give developers the means to run their own test environments directly on their local system saving both you and QA a lot of time and hassle. Imagine simply giving the disk image you used to install the production instance configured with cfengine to the developer to run! Now any configuration change you make in the master test environment can be broadcast right to the developer's machine.

You've heard it before, right? The standard answer given by so many developers when faced with a broken feature on the test server: “…but it runs on my box…”. Oh yeah, one of my favorites. You're supposed to get this released and they can only come up with this lame excuse.

Why does every developer on the planet answer in this same way? It's probably safe to assume that, indeed, it does run on their box. So what's the real problem here? The developer wants to see his feature running live in production just as much as you and the product owner. Now you tell him that his code doesn't even run. Even if you didn't intend to blame him, he'll always interpret it that way. Because his brainchild does not perform, he takes it personally. He really put a lot of effort into designing and coding. He created clean, tested code, and made sure that his feature really delivers what the users need. After weeks of effort, you come back to him and say that it doesn't work. Such motivation killers don't exactly create a healthy work environment, much less foster professional respect.

Most of us have seen, or at least heard of, the Mel Gibson movie "What Women Want". It certainly is a tantalizing idea - being able to read the thoughts of other people. Now being able to read your sysadmin's mind may not be at the top of your wish list, but, I bet there were a few times it sure would have helped fathom the meaning of that chill stare of contempt from across the table.

Or, I could just tell you what they’re thinking. For starters, what will be the production usage of that new feature you’re developing? Now, I know you're not Nostradamus - but, you've thought about this, right? Any idea how many additional web server requests per user or session? What about the performance overhead of those additional database queries — what's the longest running query now? Will you need to run that cronjob every five minutes or is once a week fine? These are just a few of the everyday concerns your sysadmin has while operating your company's website. Have enough respect for his work (and yours) to do a bit of homework and come up with some numbers here.