Surgical Team or Motley Crew of Adventurers? #

I’ve read The Mythical Man-Month lately (at Geoff’s suggestion, among others) and it’s great. I definitely recommend it highly to anyone in the software development field.

In particular, I was struck by the idea of Mills and Brooks that software development could be done more effectively by a “surgical team.” That is, the experienced lead developer writes all or most of the code, and is supported by a team of people to make him more effective. While this is perhaps an effective way to capitalize on the significant difference between excellence and mediocrity in coders, it seems to me that most of the jobs on the team are today either (a) made obsolete by technological advancements, or (b) best done by specialists who float between teams. For example, Yahoo! has some of the best Javascript and CSS “language lawyers” in the world—but does every team really need one? The need for a full-time toolsmith has been all but completely surpassed by the customizability of workstations and the availability of many high-quality tools for coding and such.

The nature of software development has changed somewhat as well. We aren’t writing assembly code any more; not only do we have high-level languages, in my current project, there are no fewer than 9 different languages in use, 10 if you count regular expressions, which we all use quite frequently. [1] We aren’t all creating the same kind of stuff. Thus, there is a strong need for all of us to be experts, surgeons if you will, in our respective areas. In addition, the non-coding jobs require their own sort of specialized focus.

It occurred to me that this division of labor, where everyone depends on everyone else but everyone has a very different job, is more like a Dungeons and Dragons party than a surgical team. Each member plays a vital but remarkably different role, each owns what they do, and each is the team’s expert in what they do. As a webdev, I get consulted about front-end concerns, and am quick to ask a back-end engineer about things that touch their domain. UI questions are decided by the interaction designer; questions of product features are handled by the product manager, etc. I suspect that this is not unique to software for the web; a similar metaphor exists (or at least, could exist) for application software.

The best D&D parties are a bit formulaic, but that’s simply because a certain distribution of talents tends to be most adaptable to the most different kinds of problems.

Fighter

Not the flashiest or most prestigious role, Fighters have the lowest barrier to entry. They accumulate experience quickly, and don’t have a lot of class bonuses. (Until 3^rd Edition made them into action heroes, that is.) But their simplicity belies a focus and strength that is crucial. The fighter is the guy in the party that protects the more “thinky” types from anything that might get in their way. There can be honor and satisfaction in bashing orcs one at a time.

On a web development team, there are two archetypes that sometimes satisfy this role. The first is the diligent code monkey who might not be the most ambitious or inventive, but is good at getting things done. They are perfectly happy to churn through buglists, knocking down whatever they can. If you show them how to do something, they’ll make it work however it has to through sheer force of will—not always fast or elegant, but functional. When depended upon properly, code monkeys are a great and valuable asset.

Also in the fighter category are the producers who manage the content of the site, use the admin tools, troll for spammers, and do all the other busywork of web site maintenance. When the programmers have moved on to the next problem, they’re still working. Don’t forget them. Whenever possible, make their lives easier. They are the ones that keep your product shiny, so you can continue to be proud to have the URL sitting there on your resume.

Ranger

Rangers are good at surviving on their own. They shun convention and human society. Often a bit wild themselves, they feel more comfortable in the company of nature. Their chaotic bent can sometimes be a liability in an adventuring party, but their wide-ranging knowledge makes them hard to discount. They are fiercely independent and difficult (if not impossible) to tame.

In a programming team, this is the quintessential hacker. Most mashups are created by a single ranger acting alone. They are great at creating new things, and no browser quirk or network irregularity will stand in their way. On the other hand, they don’t always follow convention, and have a tendency to create overly clever code that is unintelligible to anyone who follows in their wake. Thus, they have to be watched closely lest they venture off.

I’ve learned a lot of great tricks and techniques from the Ranger programmers I know. I’m always a bit envious of their free approach to things, but I guess I’m just too timid to abandon convention completely. Make sure that you understand their code before you try to adapt it to your own ends—wild animals turn vicious when handled improperly.

Paladin

The paladin is the character class with the most stringent requirements. They must conform to the strictest of moral codes and demanding attribute requirements. As such, they’re rare, and respected. The paladin’s job is twofold. As a warrior subclass, he protects the party members from outside threats. However, he’s also a healer, and a leader. Charismatic and compassionate, he holds the party together by negotiating internal conflicts. Unshakably positive, he nonetheless keeps everyone going with firm conviction in the mission.

The best project managers aspire to paladin-like grace in their roles. They defend the team from the pressures of management and the monotony of GANT and PERT charts, and make sure that everyone is able to work at their top potential. When there’s a problem, they are approachable and always seek a win-win situation. By being consistently honest and righteous, they earn the respect and admiration of those both below and above them on the management totem pole.

When someone leads like a paladin, you want to get your tasks done and meet your deadlines. Not because you’re afraid of the consequences, but simply because their drive and attitude are contagious.

There are some managers that are decidedly un-paladin-like. Few things are as hazardous on a project as leadership that does not inspire confidence and commitment. Attitude is everything in a leader.

Rogue

The rogue is a highly adaptable character. They can pick locks and disarm traps, making them essential in any dungeon-faring party. Surviving in the streets and cities on his wit and stealth, a rogue comes to know the different factions and groups, and learns to navigate the urban waters. He knows how to make a buck, how to make a friend, and how to sell, and where to buy.

The product manager takes on this role for a programming team. They are often the ones who first envision the product and pitch it to management. Often the only member of a programming team with a business background [2], they settle questions of business goals and product requirements. They make the powerpoint presentations that eventually drive the development of a real software product.

The product manager, like a rogue, also sings the song of the party, talking them up when necessary and interacting with foreign powers [3]. If a product requires buy-in from another team, whether it’s a standards group in the same company or a potential outside partner, these are the people who make the calls and settle the deal. Their day is usually full of meetings.

I’ve known some developers who look down on product managers as being less technical. This is a big mistake. Their job is every bit as intellectually rigorous as ours, due to the huge amount of information that they need to be able to call forth on demand. Since they deal with features and requirements that have not even been fully envisioned, and might not exist in any form whatsoever in the market, they are even more in the world of pure thought-stuff than programmers. Make friends with your product manager, and you’ll find that they often do actually know their stuff. And after all, some rogues will stab you in the back if you cross them ;)

Mage

The mage is the general purpose wizard. They are resourceful and possess a broad understanding of all types of magic. While not specialized in their studies, they are deeply theoretical, research oriented, and possess incredible focus and discipline. Their power comes from being able to summon a wide variety of spells, but they tend to be weak and vulnerable in the chaos of melee, since they must prepare spells ahead of time.

Many experienced back-end engineers fit into this role. They tend to prefer structured approaches and strongly typed languages, and produce exceptionally high-quality code. They often have advanced degrees in computer science and are knowledgeable in the intricacies of design patterns and memory management. They excel in areas that are somewhat regular and predictable, where the environment can be controlled, and the assumptions and edge-cases checked accurately.

Dedicated programming wizards are obviously important on any programming team. However, as much as “laymen” tend to see all software as a form of magic, the truth is that mages are actually pretty rare in the development world. They are the core of the “20%” of developers who truly care about what they create and diligently work to improve their abilities. Their craft is important to them, and they approach each problem with care and precision. It is much more than just a way to pay the bills.

While dedication is important, it comes at a price. Many back-end engineers come to get out of touch with the way that “normal” people think and interact with software. Most are pretty aware of this fact; I once knew an engineer who complained that bugzilla’s user interface was obviously designed by a database expert.

Specialist Wizard (illusionist, abjurer, conjurer, etc.)

These are the wizards that have selected a certain area of magic in which to specialize, at the expense of reduced ability in some other area. They have the same theoretical focus as a mage, but instead of having a broad understanding of every type of magic, they work to gain a much deeper understanding of a single area. When it comes to solving that sort of problem, they are the best—however, in other areas, they may be lacking.

There are many “specialist wizards” in the programming world. Here at Yahoo!, there are teams that focus 100% of their time on developing PHP, or MySQL, or Apache. (Rasmus comes to mind.) The “Paranoids” team sits in the cubes adjacent to ours, and they work to make sure that all the software at Yahoo! is as bulletproof as possible. The exceptional performance team does research to help us webdevs make our pages load and run faster.

When you have a hammer, the world can begins to look like a nail. A MySQL specialist will be tempted to suggest a database schema to solve any problem, even perhaps if the problem would be better solved by some other method. You may be asking for trouble if you ask them to do something outside their specialization. However, if you have a certain task that you’re certain to need, they can be invaluable. Database optimization is a highly developed science, and it’s not always easy or simple. Good programmers are rarely security experts (or even security knowledgeable!)

If you aren’t likely to have a lot of problems in their specialty, it’s often better to consult with a specialist only if and when they’re necessary. That way a single specialist can service multiple different teams.

Sorcerer

Sorcerers are similar to mages in the types of spells that they can cast, but instead of preparing spells from a spellbook, they simply select from the spells that they know, calling them when needed. As such, they tend to be much more spontaneous. However, they do not cultivate the discipline or depth of understanding of the wizards, and so they are limited in the number of spells that they can learn. The sorcerer excels in areas that are uncharted, and their spontaneous approach to magic allows them to quickly adapt to any situation, no matter how unpredictable.

The sorcerer is the perfect corollary to the webdev, aka the front-end engineer. Web browsers are a constantly moving target, with each behaving a little differently and new versions being released all the time. While programming patterns and the “right” ways of doing things can be useful, they are often too bulky for Javascript that has to be delivered, parsed, and executed on demand. Essentially, the webdev creates software in an environment where the rules often make no sense; where the code has to work on different platforms with conflicting requirements; where speed and features are both must-haves.

I’ve only recently heard of any colleges that make any serious attempt to teach courses on web development. From what I have heard, the things they teach are pretty bad—at best out of date, at worst outright harmful. Most professional web developers that I’ve met didn’t learn their craft in school. Like the sorcerer, they simply picked up their craft as they could, and learned techniques by studying “in the wild”; that is, by viewing source and reading websites and trying things out.

I’ve said before, it takes a certain kind of crazy to want to write software in the browser. You have to love the chaos and enjoy pulling out tricks and coming up with new hacks to work around impossibly ridiculous requirements. At the same time, unlike the ranger’s free-wheeling wildness, the team’s sorcerer must have enough discipline to tame the chaos and create software with whatever degree of stability he can, in order to help create a functional and stable site.

It can be a challenge at times to find stability and see the bigger picture and not write code for a single case. Yes, yes, that hack made it work in Safari. Lovely. But it’s also going to be a nightmare to maintain, or you just ruined the accessibility. Trade-offs are always present, and as far as I can tell, only experience and a lot of mistakes can teach you how to choose wisely.

Cleric

Diligent and committed to the ethos of their higher power, the cleric summons heavenly forces to do his bidding. By making himself an instrument of the divine, he can accomplish great things. A cleric’s power comes from their will and common sense (in D&D, this is the Wisdom score), as opposed to the cleverness and wit that Wizards rely on. The cleric has the power to vanquish undead through the force of their convictions, and their healing spells make them a must-have for any party.

In a programming party, this is the role of the QA tech. These noble souls must possess tenacity and diligence far beyond what is normal or sane. They must have the conviction and tenacity to insist that every test case be faithfully executed, even if it’s “impossible” that this-or-that change would have caused a regression. When they see something in the product that doesn’t look right, they must get to the bottom of it, carefully catalog the event, and enter it into the bug queue. They help banish the skeletons by exposing them to the light, no matter where they may try to hide.

Many a programmer, close to a deadline, has remarked with exasperation, Jeez, %$!@# QA keeps making me revisit this thing, I fixed that already!, only to find, when they go through the steps in the bug report, that yes, it is indeed broken.

While they may seem difficult or inefficient or outright stubborn at times, they’re vital. Their wisdom is a balance to the programmers’

Druid

Free from any affiliations or alignment, the druid transcends the simple human existence to become one with the natural world. Unlike the clerics who request their power from a deity, the druid opens themselves up to be nature’s instrument. It is an understatement to say that they know about the wild world; they understand the ways of the animals and plants intuitively and instinctively. Always seeking the way of balance and harmony and simplicity, they do not try to change or restrict the chaos of nature, nor do they rebel against the order that sometimes comes out of that chaos.

Designers are called by many names in our industry. UEDs, Visual Designers, User Interface Architects, HCI Specialists, Interaction Designers, IAs. (Indeed, these roles are somewhat different, as the task of designing the user interface has many facets.) Whatever they’re called, their job is to understand the expectations and habits of people they’ve never met, and shape the product into something that will fit the user’s mental model. At the same time, they must understand how those models change in the face of new problems and new solutions, and be able to adapt their software properly.

Like the druid, the UED must be free from any biases that may impede their ability to find the best solution for the user, even if that sometimes means that they may take issue with business objectives. (If the business goals and the user goals cannot both be met, then the product is in real trouble, anyhow!)

Part of the UED’s task is to map out the competition’s sites, to determine where this new product fits into the current ecosystem and how the target market’s expectations may have already been set. They must sometimes balance the "ideal” way of doing something with the “common” way of doing it, simply because users have been trained in a certain way.

More Similarities

A lot of the same characteristics that make up a good party are also true of a good programming team.

1. A team should have enough members to get the job done, and no more.
2. Each member should know his role, and enjoy doing it
3. Balance is key. Each part of the task should be accounted for, and no one area should have more resources than is needed
4. Druids make so-so healers; UEDs are usually pretty good at QA. A really good sorcerer might be able to handle the magic support if it’s not too intensive; most webdevs can usually throw some kind of back-end support together. But, if a certain area of the project is significant, then it’s worth having someone who knows it best.
5. Multiclassing can make a character more diverse, but they won’t increase in levels as quickly.
6. Treasure should be distributed fairly.
7. If you have more than one mage (or sorcerer, or cleric, or druid, or whatever), they should either divide responsibilities or one should be in charge. Same for the roles on a programming team.
8. It’s hard for a fighter to know how good a wizard is, or vice versa. It takes one to know one. Make sure your team helps interview new hires.
9. Raising levels and carefully assigning skill points will lead to a more powerful character. We min-max in real life, which is why we do it in RPGs.

Like most of the essays in The Mythical Man-Month, the fundamental principles of the surgical team are valid, even if the specific roles are mostly out of date. Within each class on the adventuring party, you can sometimes see a combination of surgeon and co-pilot; sometimes the co-pilot is unnecessary, or there are two surgeons who divide up the work.

The basic idea of thinking about the programming organization in a creative way is also worthwhile, even if only as a mental exercise. I’m sure that there are other metaphors that would work equally well.

In general, I think that the motley crew of adventurers is a lot more fun than the surgical team.

2007-12-03code ecosystemsthe business