when relevant content is
added and updated.
when relevant content is
added and updated.
The argument of generalist or specialist, or “jack of all trades and master of one” (or some) has been going on in software testing long before I arrived, and may still be here after I am gone. Today I’ll try to find some deep answers about trade offs involved, borrowed from my experience in Dungeons and Dragons.
Let’s talk about wizards and swords.
If you’ve played more than five minutes of any fantasy role playing game, you probably know that wizards don’t carry swords. They don’t wear armor either. Merlin doesn’t carry a sword in the Arthurian legends, Gandolf doesn’t in Tolkein, and even uncle Andrew in Narnia did not carry a sword. According to some lore, casting spells requires hand and body motions that preclude carry weapons and armor … but that’s wrong.
The issue is specialization.
Those who have read a little bit more will remember Robert Asprin’s “Another Fine Myth”, where the Wizard’s apprentice meets Aahz. In the beginning of that story, the character explains that life is short. A wizard is focused on one thing – the casting of spells – and does not have time to learn other forms of fighting in one lifetime. Likewise fighters fight, thieves pick locks and such, and so on. In basic Dungeons and Dragons, which does not separate races from classes, only elves can fight and cast spells — and elves live thousands of years. Elves also take about twice as many experience points to advance in skill level.
To be great at something, you typical have to give up other things. So in D&D you roll up character traits like strength, intelligence, wisdom, and so on, the pick a class to match what you are good at, and pursue that class aggressively.
But that’s not the only way to do it.
Beyond Dungeons & Dragons
There is another, less popular game called GURPS – the Generic Universal Role Playing System. GURPS gave a set of rules of how people and objects interacted, then had specific rule books for game worlds – fantasy, sci-fi, detective, ice-age super-hero, robotech, there were several hundred of them. In GURPS, you are given a certain number of points to “spend” in strength, agility, advantages, traits and skills. You can also take on disadvantages and quirks to get addition points to spend on something else. In that world, the “best” wizard is probably a 98-pound weakling with no other skills, while the “best” fighter doesn’t waste time on learning anything else.
Real vocations in GURPs like spells, swordplay or archery take a large number of points to develop. Pick up a sword with no skill and you’ll fail laughably in combat. Anyone who tries to be two-skilled will be easily beaten by a specialist, and tripolist will fare even worse.
Still, GURPS, the players themselves decide how to invest their time and effort, driven by system forces, not arbitrary rules.
We have the same issue in software development … where employment market wants people to specialize in four or five things.
That seems sort of strange, doesn’t?
Back to Software Testing
Some organizations only value coding skills. Code is, after all, the very real stuff of forward progress. Like a human learning spell-casting, learning to code takes a significant investment in life energy – and staying employed takes a continual re-investment of time and energy.
Imagine working at one such place, as a tester. No CS degree, no experience in writing software, with responsibilities to do testing 35 to 45 hours a week. Perhaps the most enlightened company gives you an hour a day to learn to code; perhaps they give you an hour a day to write tooling. Attempt to compete with programmers, to show your value purely through code, and the attempt will be laughable. The list of things to do is much more than just code, and includes learning version control, build infrastructure, how to set up test environments … attempts to be more technical invariably overlap with the “ops” character class, one that some argue is obsolete, and is busy learning to cast spells themselves.
Unlike Dungeons & Dragons, in software testing there is no rule against a wizard picking up a sword. The problem is we tackle too much. Start with pairing, with coded review, with building small utilities and automating command-line processes.
Likewise, programmers, our fighter-character-class, might learn to cast a spell or two. It doesn’t have to be a big spell; a warrior that can get the opponent to sneeze or trip might disrupt a spell being cast, or confuse a group attack.
Perhaps we should be talking about fighters with a spell book.