The thief in AD&D 2nd edition

Advanced Dungeons & Dragons 2nd edition had a fairly restrictive rule system that can be summed up with a very simple example: the thief was the only character class allowed to try to hide in shadows or move silently.

Yes, it’s that simple. If you weren’t a thief, those two skills were out of your reach.

In its defense I have to say that AD&D 2nd ed. is from 1989 and the original rules are from ’74. A few years later, this nonsense was fixed because it made no sense at all.

It’s much more interesting to play under a rule system where any player can try to move silently, with the outcome depending on their skill level and their context. Obviously, trying it in metal plate armor is not the same as trying it naked in fluffy socks.

The software architect

Today, on the eve of 2017, many companies insist on setting up rule systems for how their development teams work as if they were playing a game of AD&D 2nd ed.

I’m talking especially about those teams with an “architect” figure who, much like the thief, is the only one allowed to carry out tasks related to software architecture.

Architecture as a skill

I’m totally convinced that software architecture should be treated as a skill instead of a role.

Like any skill, you can learn it, cultivate it and put it into practice whatever your level. Of course, depending on your level, the results can range from disastrous to fully satisfying, as with practicing any other skill.

Approaching software architecture as a skill instead of a role has many advantages, both for the project and for the team members.

Collective code ownership

Extreme Programming talks about collective code ownership as a way to encourage every team member to work on any part of the code, not just the parts they developed.

It invites us to question the design and the architecture, and to change any part of the code, always responsibly, of course.

The advantages are many and the benefits more than make up for it:

  • It removes bottlenecks.- Leaving the architecture in the hands of a single person doesn’t scale, and it’s also terrible for the bus factor.
  • It reduces knowledge silos.
  • It helps build a team.- When a team is built on a caste system, it’s hard to feel like you belong.
  • It encourages higher software quality. Obviously it doesn’t guarantee it, but then NOTHING guarantees it.
  • It makes it easier for the team’s level to go up.- Encouraging collective code ownership means that those whose “skill” is lower tend to raise it, if they’re really interested.
  • It helps the team grow.- When the business needs the team to grow, there’s nothing like most of the team having broad knowledge of the software. Situations like “we need to check this with the architect” disappear completely. This is closely tied to the existence of knowledge silos.

Solving a problem that isn’t a software problem

Cases like these come up a lot:

  • I’m an architect because that way I earn more money.- In this case we’re talking about solving a personal financial problem, not a software one. This is typical in big corps where pay raises are tied to a classic table of roles. As a curious anecdote, many years ago I was hired as an art director for a similar reason. Even so, being called an “architect” doesn’t mean you have to act as the architecture dictator; you can still apply the principles of collective code ownership.
  • The client demands that role.- One possible answer would be: “well, don’t work with that client”. Obviously it’s a valid answer, but it’s not always realistic. In those cases nothing stops you from doing the same as in the previous point; it’s just a front for working with a client.
  • The team is very green.- The problem was putting together a poorly balanced team. This may be a good short-term solution, but a team can’t stay green forever; there should be a proactive effort to balance the team and help it mature.

The first two points have a lot to do with “cultural hacking”. For me it’s vital to be careful about how much energy goes into these hacking efforts. Sometimes it may be worth changing client/job and spending that energy on more worthwhile activities.

A cultural matter

Do I mean by this that everyone should do everything and know everything?

Not necessarily. Every team is made up of people whose skills are at different levels. Some may be stronger at one thing than others, and that’s normal. But it’s also normal for de facto leaders to emerge, something very different from the architect figure I’ve already mentioned.

A common problem is that, the moment you make one person responsible for one aspect of development, the rest of the team members automatically become completely passive about that aspect.

It’s not easy

Of course, there are a thousand cases and situations where having a figure like this can be a good idea, I don’t deny it. But I think they’re always temporary circumstances with an expiry date, which should evolve into a solid, mature and balanced team.

Clearly it’s not easy to have a balanced team where most members not only care about architecture but also have the ability to do it. But who said it was easy? Building software that lasts, stays stable and keeps a decent level of maintainability isn’t easy.

If your company’s approach is to run a churro factory that hires programmers by the kilo, maybe the idea of having architects flying over projects carving the architecture into stone tablets seems perfectly normal. But that takes us back to the previous point: adopting a solution for a problem that shouldn’t exist.

** The header image is by Svetlana Vorobyeva