Channels ▼

Isn't That Special?

Software Development

It's true that nearly all job ads require specialists. And most project teams are comprised of experts. For example, if we're using the Versant object-oriented database we need someone who understands Versant, if we're working with J2EE we need a J2EE expert, if we're applying the UML then we need a UML guru. But is specialization really the best approach?

Specialists Are From Venus
The fundamental problem with "specialists" is a lack of communication. Despite their expertise, the best Java programmer in the world and the best Oracle DBA have little in common and therefore will have great difficulties relating to one another. Without a common language, there is very little chance they will work together effectively.

How do you resolve the communication gap? You could set up a scheme where the Java expert creates some diagrams and documents that the DBA then reviews and responds to. With this approach, they'll eventually talk to each other, but the creation, review and update of this documentation requires a significant effort. To facilitate communication, wouldn't it be better if each had at least a basic understanding of what the other does? If the Java programmer understood the basics of databases and the DBA understood the basics of Java, each person would know what the other was talking about, and they could find ways to get the job done. You must look beyond specialization to be an effective software developer.

Because of this, agile software development requires practitioners with a wide range of skills. In Questioning Extreme Programming (Addison-Wesley, 2002), Pete McBreen writes "the arguments for efficiency through specialization are inconclusive for intellectual tasks. By making the programmers responsible for their own design, XP avoids the inefficiencies and miscommunications that can arise when design ideas are passed from a designer to an implementer." XP teams are typically made up of people with a wide range of skills, or at least people who are willing to work together and learn from each other. The same can be said for teams following other agile methodologies, such as Scrum, Crystal Clear and Feature-Driven Development (FDD).

Why do so many organizations stress specialization? First, because software development is complex, people deal with it by compartmentalization and then focus on those aspects that most interest them. Second, because it locks developers into their products, specialization is in the best interest of most vendors, who promote it through their certification programs. Third, the serial "waterfall" process, still predominant in many organizations, promotes the idea of phase specialists who provide artifacts to the people downstream.

At one extreme, we have specialists in a single technology or technique; at the other, generalists with a broad understanding of software development—but lacking any concrete development skills. The problem with extremes is that they're rarely the best approach for any given situation—what you really need is something in between. The answer? Become a generalizing specialist.

Generalizing Specialists
No, it's not an oxymoron: The generalizing specialist is someone with one or more technical specialties who actively seeks to gain new skills in these existing specialties and in other areas.

There are several ways to gain new skills. Reading is a good method: There are some great books and Web-based resources available; you need only to invest time to take advantage of them.

And, because the best developers understand the business environment in which they work, you need to read more than just technical publications—my favorites include Fortune, The Economist, Utne Reader and National Geographic.

Beyond theory, it's crucial to gain hands-on experience: Work with someone who has the skills that you're trying to gain. This informal form of mentoring works so well that modern software processes such as Extreme Programming (XP) and Agile Modeling (AM) include it as explicit practices (pair programming and model with others, respectively). More importantly, learning is a two-way street: Each person learns from the other. An "expert" can learn even from the novice who asks "Why do you do it this way?"

You may also want to become certified in one or more specialties. Although a certificate itself doesn't make you an expert, it does indicate that you've learned some of the background knowledge for your job. Like a university degree, certification is a great way to get your foot in the door, although you'll still need to prove that you can apply your knowledge in practice.

So what are the advantages of becoming a generalizing specialist? First, you'll have a better understanding of the overall software process, and thus be able to make sounder decisions and communicate more effectively. Second, your specialized skills enable you to roll up your sleeves and be an effective member of a project team—a skill that generalists struggle with. Third, documentation needs will be reduced because fewer internal hand-offs will be required. For example, if you must identify requirements and formulate a design, you probably won't need to create an extensive analysis model for yourself. Yes, you'll still have to perform analysis, but, as both the source and target of that analysis, you won't need to write as much documentation. Fourth, as a generalizing specialist, you're well suited to small project efforts—the vast majority of all projects. Pete McBreen observes that small teams require people who can take a project from start to finish in a short time, and that trying to pass detailed information between specialists makes little sense because it slows the process down.

Specialists whose expertise is limited to extensive knowledge in one subject are one extreme; generalists with a wide range of knowledge but no specific skills are the other. As with anything in life, extremes rarely work well; instead, you should strive for the sweet spot between the two that works best for your situation. Are you willing to face the challenge this new year and resolve to become a generalizing specialist? I did it years ago, and it worked for me.

Scott Ambler is a senior consultant with Ronin International Inc. His latest books are The Elements of UML Style (Cambridge University Press, 2002) and Agile Modeling (Wiley, 2001).

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.