What Developers Want

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.

Test environment which replicates production

Nobody likes to test their code in production, least of all developers. But just having a server called test1 isn’t enough. If you’re using a configuration management tool like cfengine, a lot of this work will be automatically done. Another handy tool is Capistrano for application deployment. Basically a set of ruby recipes you can use to both install and configure your systems, Capfiles can be kept in version control and used to build test and production environments. Besides configuration, its also vitally important to have good test data. You need to ensure that the test system is just as “alive” as production. This means regularly, anonymized production data imports in addition to all the bells and whistles which will alert the team in the event that these import processes fail. With this setup, developers can confidently deploy their code to QA and be assured that any problems will be uncovered before going live. If testing is serious business, then so is maintaining a valid test environment.

Published and updated architectural guidelines

Easily accessible, current systems and software information is vital information for every senior developer. Ideally, your cfengine policy and configuration files are all checked into the central repository, but for starters, even a simple Wiki page can save a lot of headache and misunderstandings. Accurate and detailed software version information is a must have to eliminate the “wiggle room” (and backward incompatibility problems) of deploying packaged modules and libraries. Have a basic architecture diagram which names critical systems and databases so that everyone in the company shares a common, technical vocabulary and understanding of operational hotspots (for instance, servers that are notorious for memory consumption, or disk I/O). Sharing this kind of knowledge with developers allows them to better design upcoming functionalities and keep a pulse as to what’s happening along the “front” (where customers are hammering away at your hopefully very busy servers).

Professional courtesy and respect

After all, they are your peers and you want their job about as much as they want yours! Everyone has looked at a piece of code or a script once in their lives, and asked themselves “What in the universe was that guy smoking when he wrote this?!”. Embarrassingly enough, if you’re really honest with yourself, you’ve probably even discovered some of these gems to be your own handiwork. We all are under incredible stress and report to six different bosses, so take this into consideration when reviewing someone else’s code. If you have some advice to pass along do it constructively. Keep in mind this same developer might be asked to review something you develop next!

These points might seem obvious once listed, but a lot of companies don’t practice them. What’s it like at your workplace? How far have you come in bridging the deployment gap?