Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

Specialists? We Don’t Need No Stinking Specialists

January 28th, 2008 · 2 Comments

I tend not to use specialists on my projects. I generally find I don’t need business analysts, testers, designers, etc. The exception is performance testing – I need a specialist for that. I can imagine scenarios where I would bring in dedicated testers or analysts, but these are exception scenarios, not the norm.

I’ve been wondering why this is. Other project managers I know rely heavily on specialists, particularly business analysts, to make their projects successful. One of my colleagues recently observed that I don’t need analysts because I do all the analysis myself. I guess that’s partially true – the abilities to understand business needs, analyze them, design solutions to meet them, refine designs based on feedback, implement them, and then test them effectively are prerequisites to being on my project team. I don’t work with “just” coders, testers, analysts, or other specialists unless I have a specific need for a specific skill. This need must go beyond what I consider fundamental software development, which includes a certain proficiency at analysis, design, coding, and testing.

Are these specialties valuable? Yes, absolutely. There is a craft to testing that only a few have really mastered. I am lucky enough to know a few of them, and it has broadened my perspective. The same might also be true of business analysis in software projects, I just haven’t observed it yet.

That said, I believe the importance of specialists in software projects is largely overstated for all types of specialists, including project managers. Not every project needs a dedicated PM, tester, analyst, architect, etc. You don’t need Magellan to find your way to work, and I don’t need a tester every time code gets written.

To make matters worse, division of labor across a series of specialists doesn’t often make sense, although corporate IT continues to move in that direction in spite of the gross failure of waterfall and other phase-based approaches over the last thirty years. Specialization works when the hand-off between specialists is relatively inexpensive, such as in the case of the hand-off from a framer to a sheet-rocker to a trim carpenter to a painter to a … etc. Framers don’t produce hundred page documents telling the sheet rocker what to do. It’s relatively obvious what he needs to do, and the communications mechanism for that exchange evolved very quickly into standards that are widely accepted across that industry.

This is not generally how software projects work. Instead, analysts have to produce copious documents that aren’t easily turned into design and code and tests and software deliveries. We’ve been trying to establish easy to follow standards for this hand-off for more than a lifetime. I think it’s time we accepted this and relied on upfront analysis only as a last resort.

Another scenario where specialization works is when the work requires so much knowledge that it’s impossible for a generalist to perform. Heart surgery, for instance, is not something a family doctor does. Nor would I recommend you try to restore a hundred year old work of art just because you know where Hobby Lobby is. This is, I believe, what many forms of testing are. Security testing, performance testing, usability testing, and lots of other testing areas are not for the untrained. I don’t think it applies to a lot of the run-of-the-mill software testing I see in projects around me, even though these projects have brought in specialists to do that work.

There are other reasons for bringing in specialists. Sometimes, when a team establishes a rhythm for development that is consistent and sustainable, certain activities reach a threshold where it makes sense to bring in specialists. Maintenance comes to mind, especially if the tickets tend to be fairly self-contained.

I hope nobody thinks I’m trashing the crafts of testing, business analysis, coding, etc. These are valuable and necessary, and I think that’s my point. Specialists make it easy for coders to think they don’t need to be able to test or talk to business users, and I think this is generally harmful to the software development profession as a whole. Everyone needs to be able to wear those hats to a certain degree and should focus some energy on developing their ability to play in every aspect of a project and contribute meaningfully.

If you enjoyed this post, make sure you subscribe to my RSS feed!
Stumble it!

Tags: Project Management

2 responses so far ↓

  • 1 Scott Barber // Jan 30, 2008 at 12:11 am


    Here’s how I think of it. “Specialists” should only be needed for “special” tasks. If you have “special tasks” that span the life of your project and/or span the life of *several* projects, that’s not a “special” task anymore — it’s a *core* task.

    Unless we’re talking about unionized labor, I don’t think needing specialists for core tasks is useful (and I’m not passing judgment on what unionized labor is useful *for*).

    Specialists are who we should call for short-term, isolated, tasks that no one on the core team has the skills to accomplish to an appropriate degree.

    Now, if you want to build a team of generalists who each have different areas of specialization – THAT’S a different story. Take me, for example…

    “I’m a software tester. I specialize in performance testing software systems. I also enjoy programming, UI design, networking, data modeling, and business analysis. When I’m not busy doing one of those things, you’ll often find me teaching classes full of other software testers or writing books and articles about software testing.”

    David, while I greatly appreciate the fact that you called out Performance Testing (I’d add Security Testing to your list as well) as an acceptable area to call in a specialist, remember that most performance testers got that way by being “expert generalists”. Don’t be afraid to use us as such, so long as you make performance testing our number 1 job (if you want it to actually get done) so that it doesn’t get lost in the other generalist tasks.

    Scott Barber
    President & Chief Technologist, PerfTestPlus, Inc.
    Executive Director, Association for Software Testing

    “If you can see it in your mind…
    you will find it in your life.”

  • 2 David Christiansen // Jan 30, 2008 at 7:38 am

    You know, I would love to have a tester on my team who can talk to business users, understand their needs, write code from scratch or tweak code others have written, and then test like it’s going out of style. Even if they weren’t a great coder, I would welcome them wholeheartedly on my projects.

Leave a Comment