Why the traditional division of roles fails in software development

The traditional split into architects, designers, administrators, database specialists and a manager on top is the biggest mistake in software engineering. Why do projects without architects or database specialists succeed while projects that fill every one of these roles collapse? It’s because we lose touch with what development is about, delivering the finished product. Putting each specialty in its own box weakens everyone’s understanding of the problem as a whole.

Does that work in real life? I don’t buy the idea that it can’t be compared. Analogies are great. Imagine one group writes a recipe for a cake. Another group interprets it as best it can, mixes the batter, puts it in the oven and sets it to bake. Then another group watches the oven temperature to make sure it doesn’t burn. An entirely different group gets it on a plate. They’re diabetic, so they won’t eat the damn cake anyway. I tap my forehead at this, since I know next to nothing about cooking and even less about baking cakes. Even so, I can imagine one cook being there from understanding the recipe through tasting the finished cake.

I wouldn’t look for an analogy in a bakery turning out rolls on a conveyor belt. Software development is anything but churning out identical products.

Another problem is what passes for collective ownership. Each role owns only a piece of the problem and hardly cares what trouble the next role will have. The designer’s work ends at the user interface. The architect designs something the developers can’t build or that misses the point altogether. Developers make something Operations has no tools for. Add a manager, usually an artificial role we have only because we split development into roles and filled them with people who can’t communicate. It’s a vicious circle of tossing problems around like hot chestnuts.

It’s as if whoever designed this arrangement forgot to switch their brain from program design to the real world. We design roles like objects, each with its own responsibility and interface. Unlike in a program, though, for better or worse we don’t control the context in the real world, with details like relationships, personal ambitions and any number of other factors.

All wrong. Back up the trees, friends.

One key to successful development, pardon me, one of the keys, is to resist having a specialist for everything. There’s one role called software developer. A developer can design, test, deploy and maintain code, and put out fires when they arise. Some developers are experienced and some aren’t. I deliberately avoid calling them better or worse. That’s why developers usually work with others. I put developers into groups, balancing what each group needs to deliver with what its members know how to do.

There are still people who aren’t primarily software developers but take responsibility for particular areas. Anarchy can only go so far.

I really like what we’re trying at GoodData. I can’t say we’re doing it yet, but we’re on the way, and it’s called DevOps. If you haven’t heard of DevOps, try episode 39 of the podcast. The roles don’t merge entirely, but the distinction between some disappears. One person takes the code from its design and prototype through implementation, testing and deployment. That changes details. They’ll get the logging right instead of doing a half-hearted job, because that log will be all they have when something goes wrong. The same goes for deployment or the database, where they’ll have to work with someone responsible for production to make sure it’s backed up.