In a widely-linked blog post ranting about devops, Jeff Knupp writes:

I know I’m going to get a ton of hate mail, but there is a hierarchy of usefulness of technology roles in an organization. Developer is at the top, followed by sysadmin and DBA. QA teams, “operations” people, release coordinators and the like are at the bottom of the totem pole. Why is it arranged like this?

Because each role can do the job of all roles below it if necessary.

This is, sadly, not the case.

I’ve known plenty of people who could crank out code, but who couldn’t maintain a stable and secure production environment to save their lives. In fact, earlier this year I got pulled in to fix up the security issues on a production system that had been installed and maintained by developers until flags were raised about its dozens of gaping security holes. Anyone who can write Java code in Eclipse on Windows can obviously set up a secure production Linux server with a J2EE stack, right? Wrong.

Similarly, managing a release requires project management skills which many developers simply do not have, not to mention some everyday human interaction skills which many of them have somehow managed not to develop. Even making sure the technical issues get dealt with can be a problem for developers. At one company I worked for, one of the development teams had been doing their own release management. It was eventually discovered that there was only one desktop PC that could actually assemble a release build of the company’s main product. Perhaps the developers theoretically could have implemented a system that allowed repeatable builds to be triggered on any machine, or at least documented the required build environment, but it didn’t look that way. Whether they lacked the skills or simply didn’t value the task — or quite possibly both — the outcome was the same, a disaster waiting to happen.

Then there’s QA. Developers love to view them as basically trained apes banging randomly on keyboards until something breaks, but testing software well requires a kind of malicious naïvety and inventiveness. You have to learn to think like an end user who knows nothing about the internals of the system. That’s a hard trick to pull off if you wrote it, which is why no matter how much you test your code yourself, someone will always find an ‘obvious’ and embarrassing bug.

More generally, the ’totem pole’ idea reflects a common geek mindset: “Anything I haven’t studied and don’t want to do, must obviously be trivial.” Ask mathematicians what they think of physicists, ask physicists what they think of chemists, and then ask chemists what they think of mathematicians.

I’ve found that most things get more and more complicated and interesting the more you examine them. I know next to nothing about sports, for example, but I know that there are people who spend hours on statistical analyses, tactical studies, research into biochemistry and sports medicine, the engineering of sporting equipment, and so on.

So if you’re inclined to think of documentation as pointless time-wasting anyone could do, or you think that product management is trivial, try studying them a bit. You might be surprised.

Yes, even marketing.