The Development Isolation Layer

by Rob Galanakis on 28/08/2010

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.


There are 3 comments in this article:

  1. 4/09/2010Free4 says:

    The complex world of extreme programing mostly in game development requires each individual to effectively work as a contractor under the roof of the company that employs them full time.
    A self managed entity that can be given a task at a high level and do all the recon themselves then task it and estimate, then maintain the dependency links and communications and promised delivery dates.
    Unfortunately the human condition blinkers a good number of development staff’s ability to perform like this and those that have these blinkers nail it for the rest of us that are capable of working this way.
    Management then steps into enforce the ISO 9001 consistency methodologies to try to ensure returns of gobs of cash to investors and you arrive at the core of the issue you speak too. A cog in a machine that is unable to apply efficiency’s as required due to standardization enforced by the PM. Leading to frustrations and broadly pissed off employees.
    A team comprised of people that work blinkered by the human condition will be self managing within the guidelines of the project’s current state and requirements.

    This is a tall order.
    It seems that the purse string are attempting to address this by the further rise in contract based employment sweeping the industry that likens it to the film studio mentality. This also pisses of a lot of game development staff.

  2. 4/09/2010Free4 says:

    **A team comprised of people that work unblinkered by the human condition will be self managing within the guidelines of the project’s current state and requirements. **

  3. 4/09/2010Rob Galanakis says:

    “Management of many is the same as management of few. It is a matter of organization.” – Sun Tzu

    I think the ‘Development Isolation Layer’ is more common in larger and/or more dysfunctional studios. Apparently we still haven’t figured out what ‘organization’ means. It’s content for another blog post, though.

Write a comment:

× 5 = fifteen

Switch to our mobile site