Why We Need Specialists

We need specialists because no one person can become expert at all the current technologies.

Or, as the saying goes, "Jack of All Trades, Master of None"

Here is a list of some of the current technologies, tools, patterns, concepts, languages, standards

Please add to the list, this is just a subset from my experience.

Is the emergent complex, rapidly changing, distributed, heterogeneous, global environments that some of us work in lead us to recognize WhyWeNeedSpecialists? In these projects specialists have to collaborate which is WhyWeNeedIntegrators (dare I say Architects!)

It could be argued that WeDoNotNeedSpecialists?, if we can reduce this list to a manageable set that everyone can be proficient at.

While I agree that specialization can be valuable, I don't think this list is helpful in illustrating that. I don't know of anyone who specializes in "Instance", "Pass by value", or "Layers". And many of the elements should really be grouped into one area of specialization (for example, XML/DTD/XSL/SAX/SOAP are all elements of being an "XML expert", and most of the other elements can be grouped into broad categories like "relational database expert", "networking expert", "Java expert", "OO design expert", "methodologist", etc.). --KrisJohnson

The list is attempting to illustrate that specialization is valuable - attempting to make developers feel good about their areas of expertise (chosen or not). It is in no way attempting to solve the complexity (quite the opposite). If we see there is a need for specialists and if we are WillingToChange then grouping areas of specialization I agree is a useful next step. Right now I'm more interested in if there is a perceived need or if the majority think that SpecializationIsForInsects.--PaulCaswell

The nice thing about the world moving toward the ObjectOriented (and DistributedObject?) paradigm: the skills learned with one technology can be easily applied to another, at least for developers. A couple of years ago, I was alarmed by the sheer volume of "Java" related books I was collecting compared to the two books I had for doing C programming, but quickly realized that all those books were not about Java programming per say, but about web programming, client/server programming, networking, data processing, etc., etc. The APIs were all slightly different, but the basic philosophies were the same. Then, I started XML design and implementation, which tied closely to OO principles, etc.

We still need administrators, etc., that need to specialize, but in the developer world, SpecializationIsForInsects. Besides, if I became a sole "specialist" at a specific technology, that would mean tackling the same problems, doing the same tasks day after day. How positively dreadful. -- ChadThompson

I agree that many skills are transferable across technologies. I agree that there are basic philosophies that are transferable (e.g. SevenPrinciplesOfSoftwareDevelopment, ManifestoForAgileSoftwareDevelopment). I am trying to encourage creativity and individuality and agree that doing the same tasks day after day would indeed be positively dreadful. However, I am concerned that we are not embracing diversity in the development community and too often are seeking the OneRightWay?.--PaulCaswell

The problem as I see it with becoming a specialist: technology and the software running it ages far too quickly to specialize. I've often heard the idiom that a college student that graduates with an 'applied' degree of sorts (usually some form of engineering) has about five years before the specific skills learned at the university are completely obsolete. The courses that allow you to grow as an individual/professional are usually more liberally based, such as basic physics, mathematics, etc. In my mind, software is similar: I'm sure there are plenty of Wikizens who can testify for the need to avoid specialization; the "smalltalk specialist" has likely struggled to find work as of late, while the more generic "object oriented designer/consultant" has far better prospects in the job market. -- ChadThompson

I am concerned that we are not embracing diversity in the development community and too often are seeking the OneRightWay?

Could you expand a little on this? I don't know if I am exactly sure what you mean... -- ChadThompson

The OneRightWay? is the best tool, the best language and the best method to build systems and there will be many reasons why this is so. Too often I find developers debating which technology (or tool or methodology) is better than another - I even find myself doing this!

An alternative approach is when you come across alternative views to a) learn from each other b) embrace the differences and c) explore possibilities of what could be achieved through collaboration. For example at the last ChicagoAgileDevelopers meeting there was a presentation on FeatureDrivenDevelopment, rather than explore how this could enhance ExtremeProgramming some choose to debate FeatureDrivenDevelopmentVsExtremeProgramming. To some extent I can understanding wanting to choose a technology or method to invest our time in learning, but I'm interested in acknowledging all the existing diversity and exploring what are we can do with all these--PaulCaswell

I can agree with this. However, I don't think *any* team (or company) should just adopt a methodology wholesale. Even MartinFowler made a comment during a talk that if you are interested in doing XP, do it "by the book" for only a few iterations, then make adujstments for your environment/team. I once lead a very interesting discussion by posting two flipcharts and labeling one "What Works", and "What Doesn't Work". I was amazed at the feedback that flew out. Do stuff that works, don't do stuff that doesn't work. I am interested in XP due to the fact that it spends most time on "things that work", and concentrates so heavily on team communication.

Plus, it can be noted that if you have a good team that collaborates well, it won't matter what process you adopt, it will work; smart people that get along are incredibly adaptable! -- ChadThompson

People specialize in order to be special, in order to be needed. You're asking why we need that? We don't, they do.

See Also: SpecializationSweetSpot, SpecialistsAndXp, StructureOfSpecialization, SpecializationInXp, SpecializationIsForInsects, HumbleInsect

EditText of this page (last edited November 12, 2005) or FindPage with title or text search