Dr. Dobb's | Isn't That Special?

Isn't That Special?

Each year, it's traditional to make a New Year's resolution. Personally, many people resolve to exercise more, eat vegetables or quit smoking. Professionally, folks resolve to learn a new skill, earn certification at an existing skill or eliminate a bad habit, such as not following common coding standards. While these resolutions are clearly important, they're also rather dull. Here's a more radical resolution for software professionals: "I will become more than a mere specialist and instead become truly effective at software development."

January 01, 2003
URL:http://www.drdobbs.com/isnt-that-special/184414941

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.

Advantages
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).