The Development Isolation Layer

Joel Spolsky over at Joel on Software has an excellent article from 2006, called “The Development Abstraction Layer.” The gist of it is that, developers must be abstracted from the distractions of business.

Management’s primary responsibility to create the illusion that a software company can be run by writing code, because that’s what programmers do. And while it would be great to have programmers who are also great at sales, graphic design, system administration, and cooking, it’s unrealistic. Like teaching a pig to sing, it wastes your time and it annoys the pig.

The article is spot on in its advice and ideas. However, I think there is a dangerous trend in game and software development- well, let’s not call it a trend, as it is more like an industry standard- that developers are over abstracted, and become isolated. What starts out as the sane and desirable abstraction Joel describes has morphed into a management-heavy, control of information you find in many of today’s large studios. They are manifested by Project Managers.
The job of project management is to be a key component of the ‘Development Implementation Layer,’ the substructure Joel describes that takes care of all the non-programming business needs. Project managers keep track of schedules. That means, they need to make sure things happen when they are supposed to happen, whether it is the delivery of a feature from your team or (more importantly) other teams, an IT request, or that corporate is getting those licenses for that software we requested.

This really just involves speaking to people and other teams, and writing a schedule for everything (even if, because they lack production skills, they can’t actually change the schedule). And since they’re doing all that anyway, why bother having the developers do any of this? And as long as I’m here, why don’t I just speak for/as the team?

Isn’t that just the evolution of abstracting distractions?

So what you get are meetings composed 50% of project managers, and a loss of communication between departments. You never get feature requests or bugs directly, they all have to be routed through the developer/tool user/QA, to their PM, to your PM, and then probably through your lead, before it gets to you (if it does at all). No one from another department is allowed to go to you with a question directly (unless they know you and can just ask you in person or over IM), even if it is a question that you can answer in seconds- it is routed through two project managers and maybe a lead.

This is really just the Law of Leaky Abstractions in effect. Except written by a programmer who is really fond over over-abstracting everything. You are forced to use an over-abstracted framework, which only gives you a few ways to change things in a complex underlying system. Except there’s no way to abstract some of what I need it to do, or what it needs of me, so I end up having to jump through extra hoops to add two numbers in a place where the framework won’t let me but I know it is what I want to do and it makes sense.

Project management is something like that. Their abstractions are fundamentally leaky. Or maybe not. Maybe they are actually valves that need to expunged, but project management doesn’t have a bucket and doesn’t want to disturb you by asking for yours, even though you’re going to have to mop the fucking floor anyway.

Obviously these over-abstractions don’t work. We need to discuss with other teams, coordinate schedules because it influences how we work, and we can’t just have one lead alongside a PM stand in for three, four, or a dozen developers. If we don’t have a direct line to our customers, we’re going to be ineffective. And a direct line doesn’t mean an open door at all hours, or a pager that goes off whenever a tool crashes. It means, we need to have all information about what can potentially impact what we are working on and will need to work on. We don’t need to respond to every piece of info, or read it every day, but we need to have it and filter it ourselves- having a few people control all information is a recipe for disaster.

But large studios do exactly that anyway. PMs are there to abstract, but end up isolating. It isn’t a PM’s job to decide what I need to know about what someone else is working on, and it sure as fuck is not a PM’s job (or a lead’s job, for that matter) to filter out customer feedback on the code I write and maintain. It is their job to make sure I know my priorities and schedule, and that’s about it.

-Rob